mirror of
https://github.com/jackyzha0/quartz.git
synced 2025-12-24 05:14:06 -06:00
35 lines
1.6 KiB
Markdown
35 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 |