diff --git a/content/notes/04-requirements.md b/content/notes/04-requirements.md new file mode 100644 index 000000000..96800e09d --- /dev/null +++ b/content/notes/04-requirements.md @@ -0,0 +1,8 @@ +--- +title: "04-requirements" +tags: +- info201 +- lecture +--- + +[requirements](notes/requirements.md) diff --git a/content/notes/furps.md b/content/notes/furps.md new file mode 100644 index 000000000..ddf910b03 --- /dev/null +++ b/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) diff --git a/content/notes/info-201-lectures.md b/content/notes/info-201-lectures.md index 6cd3fe3c3..e116cf971 100644 --- a/content/notes/info-201-lectures.md +++ b/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) diff --git a/content/notes/info-201-outline.md b/content/notes/info-201-outline.md index acd75c347..a926bcdd7 100644 --- a/content/notes/info-201-outline.md +++ b/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) diff --git a/content/notes/requirements-document.md b/content/notes/requirements-document.md index 57c0e1039..74baf9f9b 100644 --- a/content/notes/requirements-document.md +++ b/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) \ No newline at end of file diff --git a/content/notes/requirements-engineering.md b/content/notes/requirements-engineering.md new file mode 100644 index 000000000..ce7d66835 --- /dev/null +++ b/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. \ No newline at end of file diff --git a/content/notes/requirements-guidelines.md b/content/notes/requirements-guidelines.md new file mode 100644 index 000000000..235846457 --- /dev/null +++ b/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 \ No newline at end of file diff --git a/content/notes/requirements.md b/content/notes/requirements.md index e8ac306b7..a619070be 100644 --- a/content/notes/requirements.md +++ b/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 \ No newline at end of file