Software
Requirements: Introduction
The hardest single part of building a software system is deciding precisely what to build…No other part is more difficult to rectify later.
Fred Brooks “No Silver Bullet”
Core issue in Requirements Engineering is obvious:
Understand the problem your system must solve – typically, by understanding customer and end-user needs
It is harder than you think.
Some reasons we’ve already seen:
Common for software developers to misunderstand the business problem or user need and, therefore, to build the wrong system.
Sometimes, customers and target users don’t know or can’t describe their own true needs. Another problem for Waterfall.
Developers also must understand the work practices of end- users such that the software system solves the problem in a useful way.
COMP3297: Software Engineering 2
New product drivers: Pure inspiration – rarely
Current products don’t meet business and consumer needs Needs are met, but poorly. Users dissatisfied
New technologies create new needs
Lead to software requirements for the product.
COMP3297: Software Engineering
3
A software requirement is…
Behaviour.
Functional
A statement describing either:
– an aspect of what the proposed system must do, or
– a quality attribute that the system must have, or a constraint on the system or on its development
Those statements are the specification. You work with many kinds of information to derive them.
Some information you discover are actual software requirements, others are sources of those requirements.
COMP3297: Software Engineering
4
How and how well it must do it. Non-functional
Types are not necessarily mutually exclusive
Types of requirements information
Business requirement
High-level business objective of an organization.
Business rule
Policy, guideline, standard, or regulation that defines or constrains some aspect of the business. Not a software requirement itself but the origin of several types of software requirement.
Often, separated out. Not tied to the requirements for this system because they originate and exist beyond the boundary of the system. Collected in a Business Rules catalogue.
User requirement
Goal or task that specific classes of user must be able to perform with the system. Or a desired product property or attribute.
Functional requirement
Description of a behaviour that a system must provide under specific conditions
Feature
One or more logically-related system capabilities that provide value to a user and are described by a set of functional requirements. The “big ideas“
.
COMP3297: Software Engineering 5
Types of requirements information (cont.)
System requirement
Top-level requirement for a product that contains multiple sub- systems (some may be hardware).
Non-functional requirement
Description of a property or characteristic that a system must exhibit or a constraint it must respect.
Quality attribute
Kind of non-functional requirement describing a service characteristic or performance characteristic of a product. Can also lead to derived functional requirements.
External interface requirement
Description of a connection between system and a user, another system or a hardware device.
Constraint
Kind of non-functional requirement restricting the choices available to the developer.
COMP3297: Software Engineering 6
Exercise: What are the types of the following? (so you know where to record them)
7
Under normal operating conditions, authorization of an ATM withdrawal request shall take no more than 2 seconds.
Passengers want to check in for their flights online.
Passenger shall be able to print boarding passes for all flight segments following successful check in.
We wish to achieve a 95% positive customer satisfaction rating for our company’s services.
Non-academic staff can borrow no more than 24 books from the library at any time.
JSON shall be used as the format for all data-interchange.
Spell-checking on all data input
COMP3297: Software Engineering
Business/Domain Rules influence many kinds of requirements. Examples of documenting them:
For IKEA (Hong Kong) sales system:
Rule ID
Rule
Volatility
Source
Delivery-002
Delivery rates to HK Island, Kowloon and NT:
Total order <= $1000: $100
Total order > $1000, <= $3000: $200
Total order > $3000: $250
Delivery by staircase: add $50 per floor up to 8 floors
Reviewed annually and thresholds/rates may change as a result.
High volatility in planning support systems for “what if” exploration of service pricing policies.
Company policy
Indicates need to support configurable thresholds and rates. Pluggable in
planning support systems (pluggable business rules).
COMP3297: Software Engineering 8
Indicates need to control permissions/access rights. Also important for UX (“no false hope”).
COMP3297: Software Engineering 9
Rule ID
Rule
Volatility
Source
AS/P- Permissions- 02
Only the Clinic Manager can place an order, and only for their clinic.
Unlikely to change.
Hospital Authority policy
Need a good knowledge of the relationships between types of
information to develop good software requirements.
Ovals: types of information.
Business Requirements
Vision and Scope “Document”
User Requirements
User Requirements “Document”
WHY the organization or users need the system – the “business” benefits
Dark arrows: type of information stored.
Rectangles: stores of information. May not be in a physical document.
WHAT the user must be able to do with the system to satisfy business requirements
Example: It’s clear that User Requirements have their origin in and are influenced by the Business Requirements.
So, we must understand Vision and Scope early to know whether a user
request is relevant, and to ask the right questions to elicit requirements.
COMP3297: Software Engineering 10
Project Vision
For projects of all kinds, this is a vital document. Needed before detailed requirements can be specified because it is the basis for those requirements.
It outlines the business objectives and describes the product that will achieve them. This provides direction and priorities for the entire project. Without these, the project will likely be a disaster!
See later: For smaller pieces of development, write a Design Doc to provide this sort of information together with details of the proposed solution and alternatives considered.
COMP3297: Software Engineering 11
Business Requirements
Vision and Scope “Document”
User Requirements
User Requirements “Document”
Light arrows: the information is the origin of, or influences, the indicated type of requirement.
COMP3297: Software Engineering 12
Other levels and relationships?
Now can complete the levels of requirements
WHY the organization needs the system – the Requirements business benefits
Vision and Scope “Document”
Business
User WHAT the user must be able to do with the system to
Requirements
satisfy business requirements
User Requirements “Document”
Functional + Requirements
Non-Functional Requirements
WHAT the developers must deliver to satisfy user requirements
Software Requirements Specification/Product Backlog
COMP3297: Software Engineering 13
Vision and Scope “Document”
User Requirements
User Requirements “Document”
Quality Attributes
System Requirements
Functional Requirements
External Interfaces
COMP3297: Software Engineering
14
Business Requirements
Business Rules
Constraints
Software Requirements Specification/Product Backlog
Final product:
Software Requirements Specification (SRS)
An SRS documents both the functional and non-functional requirements
SRS is the basis for planning, design and system/user acceptance testing, but does not contain those details itself.
The only focus of the SRS is “what must the system provide”.
SRS can take many forms. Required level of formality will vary greatly depending on the system being specified.
The need for detailed documentation clearly will be different for a safety- critical system compared with a straightforward, non-critical web application.
In less critical systems, the level of detail will depend on how closely the developers can work with customers.
COMP3297: Software Engineering 15
Traditional Requirements
In Waterfall-like projects, teams have very little interaction with customers and stakeholders after actual development begins.
Feature M
The SRS is the official record of what the developers must
implement and it defines the requirements in precise detail.
COMP3297: Software Engineering 16
Refactor A
Feature Q
Typical Table of Contents of the SRS
1. Introduction
1.1 Purpose
1.2 Document Conventions
1.3 Project Scope
1.4 References
2. Overall Description
2.1 Product Perspective
2.2 User Classes and Characteristics
2.3 Operating Environment
2.4 Design and Implementation Constraints
2.5 Assumptions and Dependencies
3. System Features
3.1 System Feature 1
3.2 System Feature 2
3.3 …(and so on)
4. Data Requirements
4.1 Logical Data Model
4.2 Data Dictionary
4.3 Reports
4.4 Data Acquisition, Integrity, Retention,
and Disposal
5. External Interface Requirements
5.1 User Interfaces
5.2 Software Interfaces
5.3 Hardware Interfaces
5.4 Communications Interfaces
6. Quality Attributes
6.1 Usability
6.2 Performance
6.3 Security
Feature M
6.4 Safety
6.5 [Others as relevant]
Refactor A
7. Internationalization and Localization Requirements
8. Other Requirements
Feature Q
Appendix A: Glossary Appendix B: Analysis Models
COMP3297: Software Engineering
17
Section 3 itemizes functional requirements for each feature, traditionally in the form:
3.1.1 The system shall… 3.1.2 The system shall… 3.1.3 …
SRS in Agile Development?
Agile projects often don’t produce an SRS at all. The following are used instead:
Vision and Scope Document (or Design Doc). A dynamic Product Backlog capturing:
Ø User requirements as User Stories/Use Cases, with UI outlines and Acceptance criteria added as concrete detail
Ø Items of work needed to satisfy non-functional requirements Neither are analysed in detail until they enter an iteration Evaluations of product increments (working software)
COMP3297: Software Engineering 18