mirror of
https://github.com/jackyzha0/quartz.git
synced 2025-12-24 13:24:05 -06:00
36 lines
1.6 KiB
Markdown
36 lines
1.6 KiB
Markdown
---
|
|
title: "requirements"
|
|
tags:
|
|
- info201
|
|
---
|
|
|
|
# 1 What are they
|
|
|
|
> “…descriptions of how the system should behave, application domain information, constraints on the system’s operation, or specifications of a system property or attribute.� - Kotonya and Sommerville, 2001, p. 6
|
|
|
|
> “…a statement of need, something that some class of user or other stakeholder wants.� - Alexander and Stevens, 2002, p. 8
|
|
|
|
Requirements are something an information system should do, or some constraint it should adhere to
|
|
|
|
There two types of requirements. Functional requirements specify what the system should do. And constraints, which limit the way in which the system should do those things.
|
|
|
|
|
|
# 2 How are they created
|
|
|
|
Requirements should be developed using the [requirements-engineering](notes/requirements-engineering.md) process. This process defined a robust way to develop requirements. It has three main steps: discovery, documenting, and maintenance.
|
|
|
|
Requirements can be defined using the [FURPS](notes/furps) framework. However, this is usually overkill.
|
|
|
|
Requirements can be communicated through natural language, [models](notes/models.md), [prototyping](notes/prototyping.md),
|
|
or even formal mathematical notation
|
|
|
|
Good requirements should adhere to [these](notes/requirements-guidelines.md) guidelines.
|
|
|
|
Every development process has a different apporach to guidelines. ... #unfinished
|
|
|
|
# 3 What causes bad requirements
|
|
|
|
- domain and/or problem not well understood
|
|
- misnderstandings
|
|
- continually evolving or incomplete/abmiguous/inconsistent/overlapping/unimplementable requirements
|