TDDC88/TDDC93
Requirements: Requirement Engineering - What is it's usage? What kind of keywords are
important to use in a requirements specification? -
Usage: Clarify requirements for a product to avoid misunderstandings of the product,
and to specify what is to be delivered in the end of the project.
Note: Important to use MODAL VERBS such as "SHALL", "MUST", "WILL".
Requirements: Elicitation - What is it? -
An activity within requirements development that identifies sources for requirements
and then uses elicitation techniques (e.g., interviews, prototypes, facilitated workshops,
documentation studies) to gather requirements from those sources.
Requirements: Analysis - What is it? -
Classifying and resolving conflicts between requirements
Requirements: Analysis - What classes of analysis exists? -
* Functional vs. Non-functional
* Source
* Product or process requirements
* Priority
* Scope - Affected components
* Stability
Requirements: Analysis - Name the three biggest "conceptual modeling" models used in
analysis. -
* Use-cases
* Class-models
* ER-modeling
Requirements: Use-Case modeling - Diagram. -
Create a box (rectangle) that symbolizes the "machine" being used. Inside the box,
write different cases of usage, and link these usages to each person that might use the
machine.
Example: Use-case for a coffee-machine. A person named "CoffeeDrinker" can use the
machine by "Buying a cup of coffee". A person "Service" might use the machine for
"Cleaning the machine" and "Collect coins".
Look it up in the slides, or in the summary document.
Requirements: Use-Case - Description -
A Use-Case most likely will come with a use-case description. The goal of the
description is to describe a scenario for when the specified machine is in use.
Example using the coffee-machine used in the lectures:
1|Page
,A person "CoffeeDrinker" approaches the machine with his cup and a coin of SEK5. He
places the cup on the shelf just under the pipe. He then inserts the coin, and press the button
for coffee to get coffee according to default settings. Optionally he might use the other
buttons to adjust the strength of the coffee and decide to add sugar and/or milk. The machine
processes the coffee and bell when it is ready. "CoffeeDrinker" takes his cup from the shelf.
Requirements: Class model - Diagram -
The class-model diagram is somewhat more advanced than the use-case.
The diagram consists of different boxes, each box representing a part of the machine- and
user-process. Each box is connected to at least one other box, sometimes more than one. For
each connection, a quantity of each of the boxes is required, stating how many of respective
box CAN be used at the given action. Each connection between boxes has a keyword that
states WHAT the action between the boxes does.
Look up a picture of it, can't be bothered to write this all out in the future lol.
Look it up in the slides, or in the summary document.
Requirements: Class-model - Does the Class-model require a description? -
Not usually. No information given on what a description SHOULD look like. Make
something up if required.
Requirements: ER-diagram - What is it? -
The ER-diagram describes relations between objects, and lists attributes to objects.
Small example: ER-diagram between a STUDENT and a COURSE. The STUDENT has a
relation to the COURSE by being ENROLLED-IN the COURSE. The STUDENT can have
several attributes, such as NAME, PERSONAL NUMBER, AVARAGE GRADE. The
COURSE can aswell have different attributes, such as SUBJECT, COURSE CODE, e.t.c.
Requirements: Specification - What is it? -
A "Software Requirements Document" a.k.a. "Software Requirements Specification"
(SRS for short) is an official documentation of WHAT should be implemented to the projects
object.
Requirements: Specification - What are the 5 main parts of a SRS (Software Requirements
Specification)? -
* Functionality - What the software should do
* External interfaces - How it interacts with people and other software
* Performance - Speed of functions e.t.c.
* Attributes - Portability, maintainability, security e.t.c.
* Design contraints - Language, policy, required standards, laws, e.t.c.
Requirements: Specification - Should the SRS cover design details? -
NO! Leave this to the design part of the project instead of the requirements.
Requirements: Specification - Name 4 pros of SRS. -
1) Good checklist
2) Adaptable to organization
2|Page
, 3) Flexible in detailing requirements
4) Not everything specified in the SRS needs to be implemented
Requirements: Specification - Name 3 cons of SRS. -
1) Time: Takes time to read and understand the SRS
2) Broad: Usually very general and broad descriptions, needs to be tailored to the product.
3) Is not a guarantee for a good SRS - could produce a bad SRS. (I have no idea, just copy-
pasting this one.)
Requirements: Characteristics of good requirements and a small description of each
characteristic. -
1) Unitary (Cohesive) - The requirement addresses one and only on thing.
2) Complete - The requirement is fully stated in on place with no missing information.
3) Consistent - The requirement does not contradict any other requirement and is fully
consistent with all authoritative external documentation.
4) Non-Conjugated (Atomic) - The requirement does not contain conjunctions
5) Traceable - The requirement meets all or part of a business need as stated by stakeholders
and authoritatively documented. It specifies no more and no less than what is required.
&) Current - The requirement has not been made obsolete by the passage of time.
7) Unambiguous - The requirement is concisely stated without recourse to techincal jargon,
acronyms (unless previously defined in the document). It expresses only facts and not
opinions. It is subject to only one interpretation. Negative statements are avoided.
8) Specify importance - The requirement must specify a level of importance.
9) Verifiable - The implementation of the requirement can be determined through basic
possible methods such as inspection, demonstration, testing or analysis.
If you nail all these flawlessly, hit me up and I will buy you a beer.
Requirements: User stories - What are they, and what do they look like? -
A user story is a very simple case, describing WHAT a PERSON want for a certain
BENEFIT.
It will always (at least most of the time) contain an actor (person), an object, and specify a
benefit.
Example: As a STUDENT (actor) I want FLASHCARDS (object) to study on, so that I may
PASS THIS TEST (benefit).
Requirements: Validation (Formalization) - What are some ways to validate requirements
specifications? -
1) Prototyping
2) Simulation
3) Software Reviews
4) Model checking
5) Formal proofs
6) Acceptance testing
Requirements: What is a "Functional requirement"? -
A functional requirement describes the functions that the software is to execute.
3|Page
Requirements: Requirement Engineering - What is it's usage? What kind of keywords are
important to use in a requirements specification? -
Usage: Clarify requirements for a product to avoid misunderstandings of the product,
and to specify what is to be delivered in the end of the project.
Note: Important to use MODAL VERBS such as "SHALL", "MUST", "WILL".
Requirements: Elicitation - What is it? -
An activity within requirements development that identifies sources for requirements
and then uses elicitation techniques (e.g., interviews, prototypes, facilitated workshops,
documentation studies) to gather requirements from those sources.
Requirements: Analysis - What is it? -
Classifying and resolving conflicts between requirements
Requirements: Analysis - What classes of analysis exists? -
* Functional vs. Non-functional
* Source
* Product or process requirements
* Priority
* Scope - Affected components
* Stability
Requirements: Analysis - Name the three biggest "conceptual modeling" models used in
analysis. -
* Use-cases
* Class-models
* ER-modeling
Requirements: Use-Case modeling - Diagram. -
Create a box (rectangle) that symbolizes the "machine" being used. Inside the box,
write different cases of usage, and link these usages to each person that might use the
machine.
Example: Use-case for a coffee-machine. A person named "CoffeeDrinker" can use the
machine by "Buying a cup of coffee". A person "Service" might use the machine for
"Cleaning the machine" and "Collect coins".
Look it up in the slides, or in the summary document.
Requirements: Use-Case - Description -
A Use-Case most likely will come with a use-case description. The goal of the
description is to describe a scenario for when the specified machine is in use.
Example using the coffee-machine used in the lectures:
1|Page
,A person "CoffeeDrinker" approaches the machine with his cup and a coin of SEK5. He
places the cup on the shelf just under the pipe. He then inserts the coin, and press the button
for coffee to get coffee according to default settings. Optionally he might use the other
buttons to adjust the strength of the coffee and decide to add sugar and/or milk. The machine
processes the coffee and bell when it is ready. "CoffeeDrinker" takes his cup from the shelf.
Requirements: Class model - Diagram -
The class-model diagram is somewhat more advanced than the use-case.
The diagram consists of different boxes, each box representing a part of the machine- and
user-process. Each box is connected to at least one other box, sometimes more than one. For
each connection, a quantity of each of the boxes is required, stating how many of respective
box CAN be used at the given action. Each connection between boxes has a keyword that
states WHAT the action between the boxes does.
Look up a picture of it, can't be bothered to write this all out in the future lol.
Look it up in the slides, or in the summary document.
Requirements: Class-model - Does the Class-model require a description? -
Not usually. No information given on what a description SHOULD look like. Make
something up if required.
Requirements: ER-diagram - What is it? -
The ER-diagram describes relations between objects, and lists attributes to objects.
Small example: ER-diagram between a STUDENT and a COURSE. The STUDENT has a
relation to the COURSE by being ENROLLED-IN the COURSE. The STUDENT can have
several attributes, such as NAME, PERSONAL NUMBER, AVARAGE GRADE. The
COURSE can aswell have different attributes, such as SUBJECT, COURSE CODE, e.t.c.
Requirements: Specification - What is it? -
A "Software Requirements Document" a.k.a. "Software Requirements Specification"
(SRS for short) is an official documentation of WHAT should be implemented to the projects
object.
Requirements: Specification - What are the 5 main parts of a SRS (Software Requirements
Specification)? -
* Functionality - What the software should do
* External interfaces - How it interacts with people and other software
* Performance - Speed of functions e.t.c.
* Attributes - Portability, maintainability, security e.t.c.
* Design contraints - Language, policy, required standards, laws, e.t.c.
Requirements: Specification - Should the SRS cover design details? -
NO! Leave this to the design part of the project instead of the requirements.
Requirements: Specification - Name 4 pros of SRS. -
1) Good checklist
2) Adaptable to organization
2|Page
, 3) Flexible in detailing requirements
4) Not everything specified in the SRS needs to be implemented
Requirements: Specification - Name 3 cons of SRS. -
1) Time: Takes time to read and understand the SRS
2) Broad: Usually very general and broad descriptions, needs to be tailored to the product.
3) Is not a guarantee for a good SRS - could produce a bad SRS. (I have no idea, just copy-
pasting this one.)
Requirements: Characteristics of good requirements and a small description of each
characteristic. -
1) Unitary (Cohesive) - The requirement addresses one and only on thing.
2) Complete - The requirement is fully stated in on place with no missing information.
3) Consistent - The requirement does not contradict any other requirement and is fully
consistent with all authoritative external documentation.
4) Non-Conjugated (Atomic) - The requirement does not contain conjunctions
5) Traceable - The requirement meets all or part of a business need as stated by stakeholders
and authoritatively documented. It specifies no more and no less than what is required.
&) Current - The requirement has not been made obsolete by the passage of time.
7) Unambiguous - The requirement is concisely stated without recourse to techincal jargon,
acronyms (unless previously defined in the document). It expresses only facts and not
opinions. It is subject to only one interpretation. Negative statements are avoided.
8) Specify importance - The requirement must specify a level of importance.
9) Verifiable - The implementation of the requirement can be determined through basic
possible methods such as inspection, demonstration, testing or analysis.
If you nail all these flawlessly, hit me up and I will buy you a beer.
Requirements: User stories - What are they, and what do they look like? -
A user story is a very simple case, describing WHAT a PERSON want for a certain
BENEFIT.
It will always (at least most of the time) contain an actor (person), an object, and specify a
benefit.
Example: As a STUDENT (actor) I want FLASHCARDS (object) to study on, so that I may
PASS THIS TEST (benefit).
Requirements: Validation (Formalization) - What are some ways to validate requirements
specifications? -
1) Prototyping
2) Simulation
3) Software Reviews
4) Model checking
5) Formal proofs
6) Acceptance testing
Requirements: What is a "Functional requirement"? -
A functional requirement describes the functions that the software is to execute.
3|Page
