Week 1 Flashcards
What is a requirement?
A statement expressing a need (capability) and its associated constraints
and conditions
What is the goal of a requirement specification?
Enable an agreed understanding between stakeholders
Requirements document
Attributes
- Collection of requirements
For each requirement: - Identification
- Dependencies
- Source(s)
- Rationale- reasoning
- Priorities (MoSCoW – Must have, Should have, Could have, Won’t have)
Steps for requirements specification
- Identify actors and their goals
- Specify inputs, outputs of the system
- Write requirements
Steps for requirements specification given informal text
- Identify the system
- Identify actors and their goals
- Specify inputs, outputs of the system
- Go through text sentence by sentence, try if sentence gives rise to one or more requirements
Requirement Engineering
Process of getting from user needs to requirement specification is called requirement engineering:
1. Requirement elication
2. Requirement specification
3. Requirement verification and validation
4. Requirement management
Requirement elication
3.2.1 Requirement elication (requirement gathering)
- Interviewing
- Brainstorming
- observing
- Task analysis
- Scenario-based analysis
- Prototyping
- use case analysis
Requirement specification
Requirement specification
once requirements are understood the problem can be described
Requirement verification and validation
Requirements validation: focuses on ensuring that the software correctly implements a specific function.
Requirements verification: ensures that the requirements specification itself satisfies its quality criteria.
Requirements management
Requirements are hardly ever stable, and a good requirements management process allows for changes in the requirements during the process.
”The electric car drives using only electric power but carries a generator on
board that burns regular fuel. When the battery level drops below 15%,
the generator is started automatically. The generator cannot be started if
the fuel tank is empty.”
Actors?
Inputs?
Outputs?
R1?
Actors: controller, generator, fuel sensor, battery level indicator
Inputs: fuel level, battery level; outputs: start generator signal, out of fuel
R1: When the battery level indicator shows the battery level is below 15% and the fuel level is greater than 0, the controller should set the start generator signal within x seconds
What are good requirements?
- Necessary
- Appropriate
- Unambiguous
- Consistent
- Complete
- Singular
- Feasible
- Verifiable
- Correct
- Conforming
NASVUFCCCC
Semi-formal requirements – ISO29148
[Condition][Subject][Action][Object][Constraint of Action]
- [Condition] when is the requirement applicable
- [Subject] actor, e.g., “the application”, “the system”, “the librarian”
- [Action] action or verb of requirement, e.g. “shall return to”, “shall send”
- [Object] of the action, e.g., “message”, “book”, a particular state
- [Constraint of Action] restriction on the action, e.g., time limit
“When signal x is received, the system shall set signal x received bit
within 2 seconds.
Identify the [Condition][Subject][Action][Object][Constraint of Action]
When signal x is received [Condition], the system [Subject] shall set
[Action] signal x received bit [Object] within 2 seconds [Constraint of
Action]
Use cases
Use case
* Fundamental concept of many object-oriented development methods
Use case diagram
* Expresses expectations of customers/stakeholders
* Essential for detailed design
* Used during entire analysis and design process
* Can be used to answer:
* What is being described? (The system.)
* Who interacts with the system? (The actors.)
* What can the actors do? (The use cases.)