auto update

content/notes/04-requirements.md

@@ -0,0 +1,8 @@
+---
+title: "04-requirements"
+tags: 
+- info201
+- lecture
+---
+
+[requirements](notes/requirements.md)

content/notes/furps.md

@@ -0,0 +1,24 @@
+---
+title: "furps"
+tags: 
+- info201
+---
+
+The furps framwork defines a robust way of defining and categorising requirements and constraints. Requirements are split into the following five categories:
+
+- F: featurs
+- U: Usability
+- R: Reliability
+- P: Performance
+- S: Supportability
+
+There is an extended set  called furps + adds which adds:
+
+- design
+- implementation
+- interface
+- physical
+
+For example:
+
+![](https://i.imgur.com/SLMcUtd.png)

content/notes/info-201-lectures.md

@@ -5,6 +5,7 @@ tags:
 ---
 links: [[notes/info-201]]
 
+- [04-requirements](notes/04-requirements)
 - [06-business-functions-and-use-cases](notes/06-business-functions-and-use-cases.md)
 - [07-business-process-modelling](notes/07-business-process-modelling.md)
 - [08-business-patterns](notes/08-business-patterns.md)

content/notes/info-201-outline.md

@@ -12,7 +12,10 @@ links: [[notes/info-201]]
 - [systems-development-life-cycle](notes/systems-development-life-cycle.md)
 - [agile-development](notes/agile-development.md)
 - [predictive-adaptive-spectrum](notes/predictive-adaptive-spectrum.md)
-- 
+- [requirements](notes/requirements.md)
+- [requirements-document](notes/requirements-document.md)
+- [requirements-guidelines](notes/requirements-guidelines.md)
+- [requirements-engineering](notes/requirements-engineering.md)
 - [requirements-elicitation](notes/requirements-elicitation.md)
 - [approaches-to-systems-development](notes/approaches-to-systems-development.md)
 - [business-functions](notes/business-functions.md)

content/notes/requirements-document.md

@@ -7,10 +7,11 @@ tags:
 The requirements document is used to keep track of the requirements of a system. It hold information such as: constraints, the environment of the system, information about the domain of the system, and constraints
 
 The requirements document should include:
-- contraints
-- requirements
-- overall properties
-- systems env incl. related sys's
-- application domain information
-- constraints of development process
-
+- Information about the services and functions that the system should provide (functional requirement)
+- The constraints under which the system must operate
+- The overall (emergent) properties of the system
+	- e.g., type of server, amount of memory, etc
+- The system's environment including related systems
+- Application domain information
+- Constraints on the development process
+	- e.g., [agile-development](notes/agile-development.md)

content/notes/requirements-engineering.md

@@ -0,0 +1,28 @@
+---
+title: "requirements-engineering"
+tags: 
+- info201
+---
+
+> “…to cover all of the activities involved in discovering, documenting, and maintaining a set of requirements for a computer-based system.” - Kotonya and Sommerville, 2001, p. 8
+
+Requirements engineering is a robust methodology for the development of requirements. It is made  up of three main steps.
+
+
+# 1 Discovery
+
+This is where you identify all the requirments of the system. [requirements-elicitation](notes/requirements-elicitation.md) is done here. Many techniques such as [interviewing](notes/interviewing.md), [participant-observation](notes/participant-observation.md), [prototyping](notes/prototyping.md), and more are used here.
+
+This is also where you should learn about the domain of the system and the stakeholders
+
+
+# 2 Documenting
+
+This is where the requirements are specified and refined, and models and documents are created. All the requirements are compiled into a [requirements document](notes/requirements-document).
+
+
+# 3 Maintenance
+
+This occurs throughout development and is primarly focuses on managing changes in the environment of the system. 
+
+It important to manage what is being discovered and documented. This allows you to keep the client updated and manage scope creep.

content/notes/requirements-guidelines.md

@@ -0,0 +1,14 @@
+---
+title: "requirements-guidelines"
+tags: 
+- info201
+---
+
+- understandable by all stakeholders including the users
+- non prescriptive i.e., should define what, and not how
+- correct as judged by user
+- complete. i.e., there should be nothing missing from each _individual_ requirement nor the _compete set_ requirements
+- consistent. i.e., They should not contradict each toher
+- unambiguous. i.e., There should be only one one possible interpretation
+- also
+	- precise, concise, cohesive, feasible, relevant, up to date, testable, traceable

content/notes/requirements.md

@@ -4,29 +4,32 @@ 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
 
-# 1 Requirements engineering
-
-> “…to cover all of the activities involved in discovering, documenting, and maintaining a set of requirements for a computer-based system.” - Kotonya and Sommerville, 2001, p. 8
-
-Requirements engineering is a robust methodology for the development of requirements. It is made  up of three key concepts.
-
-## 1.1 Discovery
-
-This is where you identify all the requirments of the system. [requirements-elicitation](notes/requirements-elicitation.md) is done here. Many techniques such as [interviewing](notes/interviewing.md), [participant-observation](notes/participant-observation.md), [prototyping](notes/prototyping.md), and more are used here.
+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.
 
 
-## 1.2 Documenting
+# 2 How are they created
 
-This is where the requirements are specified and refined, and models are created. All the requirements are compiled into a [requirements document](notes/requirements-document)
+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.
 
-## 1.3 Maintenance
+Requirements can be communicated through natural language, [models](notes/models.md), [prototyping](notes/prototyping.md), 
+or even formal mathematical notation
 
-This occurs throughout development and is primarly focuses on manageing changes in the environment of the system
+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