L05 - Requirements Engineering Flashcards
What is a Requirement?
Requirements should state what the system should do. The design should describe how the system does this. The system’s architecture is designed to structure the requirements.
A requirement is:
- A condition or capability needed by a user to solve a problem or achieve an objective
- A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document
- A documented representation of a condition or capability as in (1) or (2)
Types of Requirements: User vs. System Requirements
User requirements are statements in natural language and are supported by diagrams of the services the system provides and its operational constraints. They are written for costumers.
System requirements are structured documents setting out detailed descriptions of the systems functions, services and operational constraints. They define what should be implemented and can be part of a contract between client and contractor. (e.g. Different mobile operation systems need to be supported, functionalities should be easily extendable…)
Functional vs Non-Functional Requirements
Functional Requirements define the provided services and describe the system functionalities, the system behavior and the system reactions. (e.g. the app shall show a costumer’s last purchase for a chosen period and the check out process must be fully integrated -> Functional requirement here is the process description and app behavior in each process step.)
Non-Functional Requirements are the specification of quality of services and constraints on the service (e.g. timing constraints, fault tolerance, exception handling). (e.g. The must respond upon request in less than 1 second, the use of the app needs to be easy for the customer)
Categories of Non-Functional Requirements
- Usability: defines how the behavior of the system must be shaped to fit the users and their work environment, e.g. intuitive interaction with the system
- Reliability: defines the dependability of the system both in time and in the fulfillment of its functions, e.g. mean time between failures.
- Performance: specifies the response time and the input-output volume that the system can handle within a particular timeframe, e.g. number of parallel accesses before response time gets acceptable
- Maintainability: specifies the ability of the system to be modified and enhanced, e.g. interdependency of system components
- Security: specifies the rights of access to the service of a system, the manner of access to those services and the tracing of interaction with the system, e.g. event logging.
Measuring Non-Functional Requirements
- Speed: Processed transactions/ second; User/ event response time
- Size: Mbytes; Number of ROM chips
- Ease of use: Training time; Number of support features
- Reliability: Probability of unavailability; rate of failure occurrence
- Robustness: Time to restart after failure; Probability of data corruption on failure
Requirements Engineering
Requirement engineering is a continuous process.
- Not all requirements are equally important
- Requirements are often not fully comprehensive from the beginning on
- Requirements can change
- Different stakeholders have different requirements
Key Requirements Engineering Tasks
Requirements Elicitation: Discover all facets of requirements; Involves all the relevant stakeholders of the project
Requirement Specification: Classifies and organizes requirements; prioritizes and negotiates; covers functional and technical analysis
Requirements Management: Documents the history of accepting new requirements; changes or drops existing requirements; traces requirements implementation
Requirement Validation: Checks if the requirements actually define the system customers really want
Requirements Elicitation
Elicitation is the process of drawing out a response from someone (e.g. a costumer), either through questioning or observing.
- Elicitation allows the development team to dig for the customers’ requirements underlying the solution to be developed
- Successful projects reflect requirements that are derived from data from a variety of sources
- Elicitation provides grounds to systematically organize, synthesize, and rationalize the data
- Rationalizing helps to reduce the number of requirements that my be in conflict or redundant
Problems of Elicitation
- Stakeholders often don’t know what they really want
- Stakeholders express requirements in their own terms
- Different stakeholders may have conflicting requirements
- Organizational and political factors influence requirements
- The requirements change during the analysis process
- New stakeholders emerge
- The business environment may change
Sources of Requirements
People: Sponsor (launch the project and decide its fate), Domain experts (most knowledgeable), Users (interact with the system), Other Stakeholders (interest are affected by the operation of the system)
Reverse Engineering: Legacy systems (existing systems the new system has to be adapted to), Existing documents (guidelines, process descriptions, manuals)
Requirements Specification
Requirements classification and organization: Groups related requirements and organizes them into coherent clusters
Prioritization and negotiation: Prioritizing requirements and resolving requirements conflicts
Requirements specification: Requirements are documented and input into the next round of the spiral
The requirement may be part of a contract for the system development and may be captured in a requirements document. The result is not a design document. It should set of what the system should rather do than how do it.
The Requirements Document
Official statement of what the development team needs to implement. It explains why a product is needed and puts them into a context. The document describes what the finished product will be like. It is an important input to validate the requirements and guides development and testing.
It should contain: Introduction; Description of the product and functionality: Listed requirements; Appendices, glossary, references, index
Users of a Requirements Document
System costumers: Specify the requirements and read them to check that they meet their needs. Customers specify changes to the requirements
Managers: Use the requirements document to plan a bid for the system and to plan the system development process
System engineers: Use the requirements to understand what system is to be developed
System test engineers: Use the requirements to develop validation tests for the system
System maintenance engineers: Use the requirements to understand the system and the relationships between its parts
How to Precisely Describe a Software Requirement
Precision: Ambiguous requirements may be interpreted in different ways by developers and user (e.g. via systematic manual analysis and regular reviews)
Completeness: They should include the full set of requirements (e.g. what is the full set of information required?)
Consistence: There should be no conflicts or contradictions in the descriptions of the system facilities (e.g. left-right issue)
In principle requirements should be both complete and consistent, but in practice it seems impossible to produce a complete and consistent requirements document
Prioritization of Requirements
Mandatory Requirements: Fulfilling a business need. Not implementing them results in a loss of costumer and revenue and has a drastic impact on the business value (contractual obligations, legal requirements, fundamental business functions).
Optional Requirements: Less degree of urgency. Implementing them may result in additional business benefits and can turn into a mandatory one (useful but not needed).
