L3: Understanding Design Needs Flashcards
What is a requirement?
Condition or capability needed by a user to solve a problem or achieve an objective
Why do we need requirements?
Badly defined requirements is one of the most common causes for software failure
3 High-level types of requirements
- Functional: functionality/behaviour that a system offers
- Quality/non-functional: qualities of the system
- Constraint: limits that cannot be influenced
Various requirements-engineering activities
- Eliciting (interviews, comparisons, etc.)
- Documenting (natural language, models,…)
- Validation (quality aspects, inspection, …)
- Negotiation (resolving conflicts, …)
- Management (prioritizing, versioning, …)
How to document requirements?
- Customer / system requirements specification (V-Model)
- Software requirements specification (ISO/IEC/IEEE standard)
- Natural language
- Software modeling
Step 1: Determine binding (MoSCoW)
MoSCoW prioritization method:
- Must have
- Should have
- Could have
- Won’t have
Step 2&3: Determine process and system activity
Define the core of the (functional) requirement
Clasify how the system acts within this core:
- Autonomously (“the system must find”)
- Via user interaction (the system shall provide a user with the ability to add”)
- By interfacing with another party/system (“the system could be able to estimate”)
Step 4: Determine on what a process is performed
Most processes are executed on something (an object)
Adding the object and additional details to the requirements:
- “the system must find the fastest route to the destination”
- “the system shall provide a user with the ability to add a destination”
- “the system could be able to estimate the arrival time”
Step 5: Determine when a process is execute
Functionalities are often execute under certain conditions
Adding conditions in the beginning:
(“as soon as” = temporal, “if” = logical, avoid “when” since it is unclear)
- “if a destination has been added the system must find the best route to that destination”
- “as soon as traffic data arrives the system could be able to estimate the arrival time”
What is a use case?
Description of how a system shall be used or should behave:
- Can involve multiple scenarios
- Makes functional requirements more concrete
- Must fulfill quality requirements and constraints
Combining models with a textual specification
Sample template for a use case:
- Identifier: Unique identifier for the use case
- Name: Unique name for the use case
- Authors: Names of the authors of the use case
- Priority: Importance of the use case
- Summary: Brief description of the use case
- Actors: List of all actors involved
- Pre-conditions: List of conditions required to start execution
- Post-conditions: List of states of the system after the main scenario
- Result: Description of what is being produced
- Main scenario: The primary scenario
- Alternatie scenarios: List of triggers for alternatives cenarios or description of alternate scenarios (possible with other post-conditions)
- Exception scenarios: List of triggers for alternatives scenarios or description of alternate scenarios
- Requirements: Related requirements
Software models
Model = abstract representation of reality
This course: Unified Modeling Language (UML)
Properties of a software system
- Structure (static representation)
- Behaviour (dynamic representation)
- Interaction (data / control flow)
What is a class versus an object
- A class is a blueprint: Defines the structure of any car in a system
- An object is the concrete instance: Creates two concrete representations of a car
