Lecture 5 (1)
Lecture 5 (1)
Lecture 5 (1)
Lecture 5
[These slides are adapted from Software Engineering: A Practitioner’s Approach, Roger
S. Pressman © 2015 & Software Engineering, Ian Somerville © 2015 ]
Requirements
Engineering- I
Topics Covered
✧ Requirements Engineering
✧ User and System Requirements
✧ Functional and Non-Functional Requirements
Learning Outcomes
✧ Understand the concepts of user and system requirements and why
these requirements should be written in different ways;
✧ Understand the differences between functional and non-functional
software requirements;
Requirements Engineering
✧ Clearly defined requirements are essential signs on the road that
leads to a successful project.
✧ They establish a formal agreement between a client and a provider
that they are both working to reach the same goal.
✧ High-quality, detailed requirements also help mitigate financial risks
and keep the project on a schedule.
✧ According to the Business Analysis Body of Knowledge (BABOK)
definition, requirements are a usable (practical) representation of a
need.
Requirements Engineering
It is essential that the software engineering team understand the requirements of a
problem before the team tries to solve the problem.
RE establishes a solid base for design and construction. Without it, resulting
software has a high probability of not meeting customer needs.
Requirements Engineering
Requirements describe the function of the system from the client's viewpoint.
The requirements must be understandable by both the client and the development
staff.
In other words: A function, constraint or other property that the system must
provide to fill the needs of the system’s intended user(s)
Engineering: implies that systematic and repeatable techniques should be used
Requirement Engineering means that requirements for a product are defined,
managed and tested systematically
Types of Requirements
BABOK, which is a recognized set of business analysis industry standards, offers the following
classification of requirements.
• Business Requirements
• User (Stakeholder) Requirements
• Product / Solution Requirements : Functional Requirements and Nonfunctional Requirements
Business Requirements
• These include high-level statements of goals, objectives, and needs.
• Business requirements do not include any details or specific features.
• They just state the problem and the business objective to be achieved such as
increased revenue/throughput/customer reach, reduced expenses/errors, improved
customer service, etc.
User (Stakeholder) Requirements
• The needs of discrete stakeholder groups (top-level managers, non-management
staff, customers, etc.) are specified to define what they expect from a particular
solution.
• This group serves as a bridge between the generalized business requirements and
specific solution requirements. They are outlined in a User Requirements
Specification and can include, for example, ability to create various reports, view
order history and status, manage customer databases, etc.
Product / Solution Requirements
Solution requirements describe specific characteristics that a product must have to
meet the needs of the stakeholders and the business itself.
• Functional Requirements define what a product must do, what its features and
functions are.
• Nonfunctional Requirements describe the general properties of a system. They are
also known as quality attributes.
What is a Requirement?
✧ A statement of what:
▪ The system must do or
▪ Characteristics it must have
✧ Analysis requirement written from businessperson perspective ( focus on the “what” of system)
✧ They focus on business user need so they usually are called business requirements (or user
requirements).
✧ Later requirements (in design phase), business requirements evolve to become more technical and
they describe “how” the system will be implemented.
✧ Requirements in design are written from the developer perspective, and they usually called system
requirements.
✧ Business requirement and System requirement are used interchangeably.
Requirements in Software Development
Feasibility and
Planning Requirements All process
models include a
requirements
activity
Design
Operation and
Implementation Maintenance
Difference between a user requirement and
a requirements specification
The term requirement generally refers to a customer need while specification refers to a detailed, usually technical description
of how that need will be met.
Requirements & Specifications
Problem domain Software (Solution) domain
Describes
problem
Specifies
Analyzes Develops
We receive “customer
problem statement,” not the
requirements!
Software Engineer
Requirement vs Specification in Software Engineering
A functional requirement defines a system or its component. A non-functional requirement defines the quality attribute of a software system.
It places constraints on “How should the software system fulfill the functional re-
It specifies “What should the software system do?”
quirements?”
Helps you verify the functionality of the software. Helps you to verify the performance of the software.
Functional and Non-functional
Requirements
Requirements are often classified as functional or non-functional
requirements
Functional Requirements
The definition of a functional requirement is:
Slide 31
Functional & Non-Functional Requirements
Examples: Examples:
User authentication Performance (response time, throughput)
Report generation Reliability
Search functionality Scalability
Usability
Security
“The system shall allow users to reset their
passwords” “The system shall achieve a response time
of less than 2 seconds for 95% of user
transactions."
Nonfunctional Requirements
In Robertson and Robertson (2006), the authors identify the following eight classes of
non-functional requirement:
• look-and-feel requirements – the spirit of the product’s appearance;
• usability requirements – the product’s ease of use, and any special usability
considerations;
• performance requirements – how fast, how safe and how accurate the functionality
must be;
• maintainability and portability requirements – expected changes, and the time
allowed to make them;
• security requirements – the security and confidentiality of the product;
• cultural and political requirements – special requirements that come about because of
the people involved in the product’s development and operation;
• legal requirements –Laws of the state
Slide 33
Look-and-feel Requirements
• Definition: Describes
Look-and-feel requirements describe the the aesthetic and
overall appearance and behavior of the perceptual aspects of the
product to its users. (the spirit of the product's appearance.
product’s appearance)
• Example: The user
interface should have a
For example, in a banking environment, we modern and visually
might want the product to have a appealing design to
conservative feel, with limited use of enhance user experience.
colors and animation. If the product is a
game, then the opposite might apply.
Slide 34
Usability Requirements
• Definition: Focuses on the
ease of use and user
Usability is the degree of ease with which the user will experience of the product.
interact with your products to achieve required goals
effectively and efficiently.
• Example: The system
Usability focuses on the appearance of the user should provide clear and
interface and how people interact with it. What color are intuitive navigation, ensuring
the screens? How big are the buttons? that users can easily
understand and interact with
the product’s ease of use the interface.
Slide 35
Performance Requirements
• Definition: Specifies how fast,
safe, and accurate the
functionality of the system
must be.
Slide 36
Maintainability and Portability Requirements
• Definition: Addresses the
ease of maintaining and
making changes to the
software, as well as its
portability to different
environments.