L06: Requirements Engineering Flashcards
What are the requirements of a system?
Descriptions of the services a system should provide and the constraints on its operation
- Reflects the needs of the customers of the system
- Can range from a high-level abstract statement of a service or of a system constraint to a detailed mathematical functional
specification
Can be the basis for
- bid for contract - should be open to interpretation
- contract itself - should be precise and detailed
How can we summarise requirements engineering?
Process of finding out, analysing, documenting and checking requirements (system services and constraints)
[Sommerville, 2016]
How do we get the requirements for a plan-driven process?
- Get from the user perspective
- Translate to system perspective
How do we get the requirements for an agile process?
As the customer is consulted throughout the development process
1. Get from the user perspective
2. Keep the features that users want from the system
What are the 3 types of requirements in a plan-driven process?
- User requirements
- System requirements
- Domain requirements
What are user requirements?
- Typically in natural language and diagrams to capture user interactions with the system
- What the system is expected to provide for customers and the constraints under which it will operate
- Written for customers (accessible to non-technical people)
What are system requirements?
- Structured document which details what should be implemented
- Can be part of contract between customer and developing organisation
- Functional and non-functional requirements (should be atomic and precise)
- 1 requirement deals with 1 functionality of the system
What are functional requirements?
- What the system should do
- May also state what the system should not do
There should be statements of
- services the system should provide
- how the system should react to particular inputs
- how the system should behave in particular situations
What are non-functional requirements?
- Specify or constrain characteristics of a system as a whole
- Often applies to the system rather than the individual features or services
- Can be more critical to a system success than individual functional requirements
- E.g. usability, performance, security, availability
What are the challenges of non-functional requirements?
- Users/customers often propose non-functional requirements as general goals instead of measurable requirements
- Scope for interpretation and subsequent disputes after system is delivered
- We can have vague requests such as “system should be easy to use”, “user errors should be minimised”
- How can we measure these requirements?
- Some requirements do not have simple metrics
- Even if quantitative specification is possible, customers may not be able to relate their needs to them
- Cost of objectively verifying non-functional requirements can be very high
What are some metrics for non-functional requirements?
Speed
- Transactions/second, response time to events
Size
-MBs
Easy to use
- Training time, support features
Reliability
- Mean time to failure, availability, rate of failure occurrence
Robustness
- Time to restart. probability of data corruption, percentage of events causing failure
Portability
- Number of target systems
What are domain requirements?
- Derived from system domain rather than user perspective
- If domain requirements are not satisfied, system may be unusable
Requirements from the operational domain
- New functional requirements
- Constraints on existing requirements
- Specific computations
- E.g., even if the users do not tell you that you need this feature, e.g. logging for an audit trail, you still need to include it if it is vital for your domain
What are some challenges with domain requirements?
Understandability
- Constraints expressed in the language of the application domain
- May not be understood by development team
- Omission and conflicts may be missed
Implicitness
- Domain experts may not realised that they need to explicitly state these requirements because they understand the domain so well (assume you would know as well)
What are the 4 activities involved in requirements engineering?
- Requirements elicitation and analysis
- Requirements specification
- Requirements validation
- Requirements management
What is requirements elicitation and analysis?
Aims
- Understand the work of stakeholders
- Understand how the new system might support this work
Requirements engineers work with stakeholders to find out about
- Application domain
- Services the system would provide
- Operational constraints
