Chapter 4 - Part I Flashcards
Requirements Engineering
What are Requirements?
▪ Statements that express what the product will look like in the future.
▪ Descriptions of services/constraints that are generated during the requirements engineering process.
▪ Crucial for the next processes and for the contract between the user and the team.
Types of Requirements.
User requirements
▪ Expresses what the system will do from the user’s point of view, using the user’s language. It is a high-level representation. (What the users want)
System requirements
▪ A user requirement expressed in a technical language. It is expressed in such a way that developers can start to build/execute the tasks. The same interactions are translated into the software developer language. (What the system will do)
Functional Requirements
▪ Requirements that tell us what services the system will do for the user, and how it should react/behave.
▪ May state what the system should not do.
▪ They describe the functionality or system services.
▪ They depend on: type of software, expected users, type of system that the software is used.
▪ May be high-level
▪ Should describe the system services in detail.
▪ When requirements are unclear, developers and users might understand them differently (they read them differently)
▪ Requirements should be both complete (they should include all descriptions of all facilities required), and consistent (there should be no conflicts/contradictions in the descriptions)
Non-functional Requirements / Classifications
▪ Restrictions/Limits that are related with the technical issues of implementing a product in a specific environment.
▪ Often apply to a system as a whole, rather than individual features/services.
▪ Define system properties/constraints (response time, storage requirements) that may arise from internal/external factors, or the product itself.
▪ May require using specific software/programming methods
▪ These requirements may be more critical than functional requirements. The system may be useless if these requirements aren’t met.
▪ May affect the overall architecture of the system (rather than individual components)
Classifications:
Product requirements
▪ Requirements which specify that the product must behave in a particular way.
Organizational requirements
▪ Rules that come from company policies.
External requirements
▪ Requirements which arise from factors which are external to the system.
Domain Requests
Constraints on the system from the domain of operation.
How to express requirements?
▪ Not write them as goals, since they’re general intentions of users.
▪ The system should be written in a way that can be easily tested.
Metrics for specifying nonfunctional
requirements
Speed: User/event response time
Size: Mbytes
Ease of use: Training time
Reliability: Availability
Robustness: Time to restart after failure
Portability: Number of target systems
Domain requirements / Problems
▪ The system needs to meet certain requirements because of where it is used.
▪ Could be new functional requirements, constraints, or specific computations.
▪ If domain requirements are not met, the system may be unworkable.
Problems:
Understandability
▪ Requirements are expressed in the language of the application domain;
▪ This is often not understood by software engineers developing the system.
Implicitness
▪ Domain specialists understand the area so well that they do not think of making the domain requirements explicit.
The software requirements document
The software requirements document is the official statement of what is required of the system developers.
Should include both a definition of user requirements and a specification of the system requirements.
It is NOT a design document.
It should set WHAT the system should do rather than HOW it should do it.
Who can access the requirement’s document?
Customers (specify the requirements and changes).
Managers (plan the 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 relationship between its parts)
The structure of a requirements document
Preface (defines the expected readership of the document)
Introduction (describes the system’s functions)
Glossary (defines the technical terms used)
User requirements definition (describes the services provided for the user. The nonfunctional system requirements should also be described in this section)
System architecture (shows the distribution of functions across the system)
System requirements specification (describes the functional and nonfunctional requirements in more detail)
System models (might include graphical system models showing the relationships between the system components and the system and its environment)
System evolution (describes the fundamental assumptions on which the system is based, and any anticipated changes)
Appendices (provides detailed, specific information that is related to the application being developed)
Index (several indexes to the document may be included)
Requirement Specification
The process of writing down the user and system requirements in a requirements document.
User requirements have to be understandable by end-users and customers who do not have a technical background.
System requirements are more detailed requirements and may include more technical information.
The requirements may be part of a contract for the system development
Ways of writing a system requirements
specification
Natural language: written using numbered sentences in natural language.
Structured natural language: written in natural language on a standard form.
Design description languages: uses a language like a programming language, but with more abstract features.
Graphical notations: graphical models, supplemented by text annotations.
Mathematical specifications: mathematical concepts.
In principle vs. in practice, for requirements
In principle, requirements should state what the system should do, and the design should describe how it does this.
In practice, requirements and design are inseparable.
Natural language specification / Problems
▪ use our language/text
▪ the requirements can be understood by users
▪ don’t add many details/be concise
Problems:
Lack of clarity
▪ making the document difficult to read.
Requirements confusion
▪ Functional and non-functional requirements tend to be mixed-up.
Requirements amalgamation
▪ Several different requirements may be expressed together.
Guidelines for writing requirements
Invent a standard format and use it for all requirements.
Use language in a consistent way.
Use text highlighting to identify key parts of the requirement.
Avoid the use of computer jargon.
Include an explanation of why a requirement is necessary.
Structured specifications
An approach to writing requirements where the freedom of the requirements writer is limited and requirements are written in a standard way.
