CMU-SE 214 Requirements Engineering - 2022S - Lecture Slides-3

lecture duration: 180’
Instructor: Dao, Nguyen Thi Anh

International School - DTU
Email: nguyenthianhdao@duytan.edu.vn
1.1 © by CMU
© by CMU Dao Nguyen Dao Nguyen
Contents
1. Description Software requirements operate on three
levels: Business, Users and Software.
2. Understand the impact of RE on the software
engineering team
3. The role of the required engineer. Before gathering
requirements, Software Engineers must define the
product vision, common terms and mitigate risks.
1.2 © by CMU
Where Do Requirements Come From?
1.3 © by CMU
Business Requirements
 ƒ tatements of the business rationale for authorizing the
S
project. They include a vision for the software product to be
built that is driven by business goals, objectives, and
strategy.
 ƒBusiness requirements describe the high level purposes and
needs that the software product will satisfy, the view of its
accomplishments for the users, its features, functions, and
capabilities from the Business point of view.
 ƒBusiness requirements are documented in the Project
Charter, Vision or Scope of the project. Sometimes it can be
found in the Statement of Work, Memo of Understanding
(MoU) or Request for Proposal (RFP).
1.4 © by CMU
User Requirements
 ƒ he definition of the entire system (hardware and software)

T
from the User’s point of view. They describe the task that
users need to do with the system to accomplish a business
function.
 ƒUser requirements are the bridge between the business goals
(Business language) and the system requirements (Technical
language). Software engineers must understand how users
will use the system and derive their requirements from the
user requirements document.
 User requirements can be found in User Requirements
Document (URD), Concept of Operations (Con OP), User
Scenarios / Use-cases or Product features document.
1.5 © by CMU
System Requirements
 Dƒ etailed descriptions of all functional as well as non-

functional requirements that the systems (Hardware
and Software) must do to meet business and user
needs.
 ƒSystem requirements define the top level
requirements for allocation to hardware, software
or subsystems from the System Engineers’ point of
view. (Manager, Architect, Designer)
 ƒSystem requirements serve as a communications
channel to users, procurement organizations, as well
as to system architects who are concerned with the
development of system elements or components.
1.6 © by CMU
Software Requirements
 ƒ etailed descriptions of all functional as well as non-functional

D
requirements that the software must do to meet system
requirements and user needs from the Developer’s point of
view.
 ƒSoftware requirements establish an agreement between
technical people and business people on what the product or
application must do while staying within the constraints of
system architecture and hardware limits.
 Software Requirements are documented in the Software
Requirements Document (SRS), Detailed Requirements
Specification or Functional Specification.
1.7 © by CMU
Relationships Of Requirements
1.8 © by CMU
System View
1.9 © by CMU
System & Software
 ƒ ystem requirements describe the behavior of the system as

S
seen from the user’s perspective.
 System requirements serve as a communications channel to
customers, users, and system architects who are concerned
with the development of system components.
 Software requirements specify how the system will be built, as
seen from the developer’s perspective.
 Software requirements serve to communicate with developers,
who need to know what is expected of the system components
for which they are responsible, as well as information about
those elements with which they must interface.
1.10 © by CMU
Key Concepts
 Requirements are WHAT the software must do (externally

observable behavior).
 Design is HOW the solution will work (underlying
mechanism).
 Example
• Customer need: keep track of time passing.
• Possible solutions: sundial, hourglass, clock.
1.11 © by CMU
Requirements Must Be …
 Correct: They must represent the real need of customers and

users.
 Complete: They include all the needed elements.
• Functionality, external interfaces, quality attributes and design
constraints.
 Clear: They can be understood in the same way by all
stakeholders with minimum supplementary explanation.
 ƒConcise: They are stated simply, in the most minimal way
possible to be understandable.
 ƒConsistent: They do not conflict with other requirements.
1.12 © by CMU
Quality Of Requirements
 The success or failure of a project depends heavily on the quality

of the requirements.
 The quality of the requirements is influenced by techniques used
during requirements elicitation because elicitation is all about
learning the needs of stakeholders, and communicating those
needs to system builders.
 Requirements elicitation is influenced by how much software
engineers understand customers’ business processes and needs.
1.13 © by CMU
Requirements Must Be …
 ƒ elevant: They are necessary to meet a business need, goal, or

R
objective.
 ƒFeasible: They are possible to implement.
 ƒVerifiable: There is a finite, cost effective technique for
determining whether the requirement is satisfied.
1.14 © by CMU
Internal Issue
1.15 © by CMU
Organization Structures
 ƒ ystem Engineer focuses on the total system which consists of

S
both hardware and software. System Engineers have ultimate
decision making on the system and interfaces with
stakeholders to obtain requirements and also have a big role in
the integration of all components to ensure systems will
function as expected.
 ƒHardware Engineer focuses on the physical aspect of the
system, they design and build the hardware system which is
very well structured and understood.
 ƒSoftware Engineer focuses on the design and
implementation of the system and ensures that the newly built
system will satisfy the needs of the stakeholders.
1.16 © by CMU
Why Requirements Are Difficult?
 ƒ ustomers and users often do not understand how software
C
design and development works, and can not explain their
needs and how the final software works for developers.
 ƒDevelopers often do not understand the problems and the
needs of customers and users to specify the requirements.
 ƒLack of communication between users and developers is the
main issue that makes requirements difficult to define.
1.17 © by CMU
Issues with Requirements - 1
 ƒ any Sales & Marketing people with limited software
M
knowledge are responsible for developing software
requirements.
 ƒLack of software skills to specify what functions and
performance a software product can be expected to meet, often
leads to serious integration problems.
 ƒUnfamiliarity with software also leads to disproportionate
allocation of requirements, resulting in starting of software
projects with unrealistic and unfeasible requirements.
 ƒMany software developers are reluctant to get involved in
requirements engineering due to a lack of business knowledge
and skills.
1.18 © by CMU
 ƒ any software companies have rigid structures with clear
M
lines of authority and control in order to ensure no one is
working on things other than what is currently assigned.
 Managers will focus on planning, scheduling, budgeting, and
ƒ
directing people.
 Programmers will focus on coding, testing and documenting.
ƒ
1.19 © by CMU
 ƒ nfortunately, many managers are not trained in the
U
managing aspect of software projects. Some are good
programmers that get promoted into management. Some come
from business and finance schools with no knowledge of
software.
 Without additional training, they will struggle with the burden
of estimating, monitoring and meeting customers’ demands
and these pressures will drive many projects to failure.
1.20 © by CMU
 ƒ any stakeholders do not understand why it is important to
M
spend more time defining requirements.
 ƒDevelopers do not like to spend time with stakeholders in
defining requirements because they like to write code and
assume that they know what stakeholders need.
 ƒBoth sides do not like to work on requirements.
1.21 © by CMU
Requirements Engineering
1.22 © by CMU
Is It Possible?
1.23 © by CMU
Requirements Engineer
 ƒ equirements engineer: a software engineer who has the

R
responsibility to gather, analyze, document and validate the
needs of the project stakeholders.
 ƒRequirements engineer: the principal focal through which
requirements flow between stakeholders and the software
development team.
 ƒThis role in collecting and disseminating project information is
critical and requires a lot of experience and training.
1.24 © by CMU
Requirements Engineer
1.25 © by CMU
Requirements Engineer’s Skills
• ƒListening skills
• Interviewing & questioning skills
• ƒAnalytical skills
• ƒFacilitating skills
• Observation skills
• Writing skills
1.26 © by CMU
Requirements Engineer’s Skills
• Oranizational skills
• ƒModeling skills
• ƒInterpersonal skills
• ƒCommunication skills
1.27 © by CMU
Requirements Engineer’s Tasks -1
1. Define business requirements

2. Identify stakeholders & user classes
3. Elicit requirements
4. Analyze requirements
5. Write requirements specifications
6. Model the requirements
1.28 © by CMU
Requirements Engineer’s Tasks - 2
7. Lead requirements validation

8. Facilitate requirements prioritization
9. Manage requirements
1.29 © by CMU
1.30 © by CMU
Requirements Engineering
Requirements Engineering consists of:

1. Requirements Development:
Requirements Elicitation(Gathering)
Requirements Analysis
Requirements Specification
Requirements Verification &Validationn
2. Requirements Management:
ƒ Requirements Baseline
ƒ Requirement Change Management
ƒ Requirements Traceability
1.31 © by CMU
From Vision To Project Scope
•
1.32 © by CMU
From Vision To Project Scope
 ƒ he product vision aligns all stakeholders in a common

T
direction. The vision describes what the product is about and
what it eventually could become.
 ƒThe project scope identifies what portion of the long-term
product vision the current project will address.
 ƒThe statement of scope draws the boundaries between what is
in and what is out (the project limitation) as the details of a
project’s scope are represented by the requirements baseline.
 ƒThe project scope is the sum of all the project’s deliverables
and services to be provided to customers & users.
1.33 © by CMU
Vision & Scope
•
1.34 © by CMU
A Product Vision Statement
 ƒ vision statement is a concise statement that defines the what,

A
why, and who will buy or use the final product from the
business point of view.
 ƒThe vision statement will help you to:
• Ensure that the product definition aligns with the business
goals and objectives.
• Identify stakeholders – Who will buy or use the product?
1.35 © by CMU
A Product Vision Statement
 ƒ he vision statement will help you to:

T
• What the product will do for its stakeholders?
• What are the reasons to buy or use this product?
• How can this product be distinguished from others?
• Describe the state of the business – its strengths, weaknesses.
• Describe the opportunities and risks to the business.
1.36 © by CMU
Follow This Template …
•ƒ
1.37 © by CMU
How To Write Vision Statement - 1
•Define the following terms:
1. Target customers: Describe the people who will use or buy the
software.
2. Statement of need: Describe what the target customer does or
what the software will help them with.
3. Product name: Provide the name of the product that you will
create.
4. Product category: Describe the type of product that you are
building. Product categories might include internal
application, COTS software, embedded software, business and
finance software, game software, complex software, etc.
1.38 © by CMU
How To Write Vision Statement - 2
•5. Benefit Statement: Describe what the product will do for the
target customers or the justification for buying the product.
6. Competitive analysis: Describe the key competing product
available or the system or process that the product will
replace.
7. Product differentiation: Explain the differences between the
product you are building and the competition.
Review all writings to ensure that they define the what, why,
and who from the business point of view.
1.39 © by CMU
Follow This Template …
ƒ• Insert statement to <>

ƒ For <target customer> Who <statement of need> the <product
name> is a <product category> that <benefit statement> unlike
<competitive analysis>, our product or service <product
differentiation>.
ƒ Review and check if the vision aligns with the business goals
and objectives.
1.40 © by CMU
Example - 1
•ƒ For a software company who provides outsourcing services to
global customers, the ABC system is the most advanced
outsourcing system that has successfully provided services to
hundreds of global clients. Unlike others who do not provide
total solutions, our services have helped many clients achieve
significant cost savings by integrating all applications into a
cohesive total business solution that brings quality and
efficiency for the entire operation.
1.41 © by CMU
Example - 2
•ƒ For software users who need to request information from
databases, the ABC Data Management is an information
system that provided a single point of access to all data and
information stored anywhere in company’s multiple databases.
Unlike other systems, our system not only locates, selects and
provides information, but also generates required reports
when needed, for use for further investigation and
documentation.
1.42 © by CMU
Example - 3
•
1.43 © by CMU
Example - 3
•
1.44 © by CMU
Vision and Scope Document -1
•
1. Business Requirements
1.1. Background
1.2. Business Opportunities
1.3. Business objectives
1.4. Customer or Market requirements
1.5. Value provided to customers
1.6. Business risks
1.45 © by CMU
•
1. Business Requirements
1.1. Background
1.2. Business Opportunities
1.3. Business objectives
1.4. Customer or Market requirements
1.5. Value provided to customers
1.6. Business risks
1.46 © by CMU
•2. Vision of solution
2.1. Vision statement

2.2. Major features
2.3. Assumptions and dependencies
1.47 © by CMU
Vision and Scope Document - 3
•3. Scope and Limitations
3.1. Scope of Initial Release

3.2. Scope of Subsequent Release
3.3. Limitation and Exclusions
1.48 © by CMU
Vision and Scope Document - 4
•
4. Business Context
4.1. Customer profiles
4.2. Project Priorities
5. Product success factors
1.49 © by CMU
Project Priorities
 ƒ here are five key factors that every project must operate:
T
Scope (Feature), Quality, Schedule, Cost and Resources
(Staff).
 ƒConstraint: A limiting factor within which the project
manager must operate.
 ƒDriver: A significant success objective with limited flexibility
for adjustment.
 ƒDegree of Freedom: A factor that the project manager has
some latitude to adjust and balance the other factors.
 ƒProject manager’s goal is to adjust those factors within
degrees of freedom to achieve the project’s success drivers in
the limits imposed by the constraints.
1.50 © by CMU
•
1.51 © by CMU
Define Common Terms
 ƒ ince stakeholders and software teams may not understand

S
each other because each is using different terms, or use the
same term with different meanings; it is important to build a
dictionary of common terms relevant to the product being
built to improve communication during requirements
gathering.
 Improve a shared understanding of the problem space.
 Enable business people to inform technical people about
important business concepts.
 Provide a foundation for defining requirements.
 Improve communication by eliminating misunderstanding in
what business concepts mean.
1.52 © by CMU
Shared Terms
 Thus, the vocabulary of the team needs to be explored and

shared throughout the effort.
 Terms such as reliability, scalability and usability may have
the general meaning, but will need to be defined into specific
statements for clarification.
 For example, if the customer indicates that the system must be
reliable, perhaps they are really thinking about the integrity of
the data flow, but the developer may think that reliability
means that the system will not crash.
1.53 © by CMU
Requirements Risks
 E
ƒ very requirement has risk which is a condition that could
endanger the project or the product development.
 Requirements risk mitigation is a process to assess
requirements-related risks and identifies actions to avoid or
minimize those risks.
 Requirements risk mitigation also helps strengthen project
team and stakeholder communication and helps the team
prepare for or prevent obstacles to successful requirements
development.
 Because requirements are critical to the project, identifying
and solving these risks can have high impact on the project
success.
1.54 © by CMU
Summary
 ƒ oftware requirements operate on three levels: Business, Users

S
and Software.
 Requirements engineering is influenced by how much
Software Engineers understand customers’ business processes
and needs.
 A Requirements Engineer is a Software Engineer who has the
responsibility to gather, analyze, document and validate the
needs of the project stakeholders.
 Before gathering requirements, Software Engineers must
define the product vision, common terms and mitigate risks.
1.55 © by CMU
Class Exercise
ƒ Identify a software product. (Ref: project list)

ƒ Ask several teams to write a vision statement for that product
using the “key word template”.
ƒ See how many of the visions are similar.
ƒ Rectify any disconnect and come up with a unified vision
statement that all teams agree to.
ƒ Discussion: Imagine each team is a stakeholder and see how
difficult it is to combine several perspectives into a single
product vision.
1.56 © by CMU
References
• Nguyen, Tam T. T. (2014). Requirements Engineering.

CMU-SE 214-2020S-REF. pp. 22-23
• Hull, E., Jackson, K., & Dick, J. (2014). Requirements
Engineering. CMU-SE 214-2020S-TEXT. pp. 93-111.
Readings:
CMU-SE 214- Vision and scope-2020S- EXTRA Reading-1.pdf
 Please watch the video at the link below:
https://www.youtube.com/watch?v=DtQU3EsssGI
1.57 © by CMU
Questions & Answers
1.58 © by CMU

CMU-SE 214 Requirements Engineering - 2022S - Lecture Slides-3

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CMU-SE 214 Requirements Engineering - 2022S - Lecture Slides-3

Uploaded by

Copyright:

Available Formats

lecture duration: 180’

Instructor: Dao, Nguyen Thi Anh

 ƒ he definition of the entire system (hardware and software)

 Dƒ etailed descriptions of all functional as well as non-

 ƒ etailed descriptions of all functional as well as non-functional

 ƒ ystem requirements describe the behavior of the system as

 Requirements are WHAT the software must do (externally

 Correct: They must represent the real need of customers and

 The success or failure of a project depends heavily on the quality

 ƒ elevant: They are necessary to meet a business need, goal, or

 ƒ ystem Engineer focuses on the total system which consists of

 ƒ equirements engineer: a software engineer who has the

1. Define business requirements

7. Lead requirements validation

Requirements Engineering consists of:

 ƒ he product vision aligns all stakeholders in a common

 ƒ vision statement is a concise statement that defines the what,

 ƒ he vision statement will help you to:

ƒ• Insert statement to <>

2.1. Vision statement

3.1. Scope of Initial Release

 ƒ ince stakeholders and software teams may not understand

 Thus, the vocabulary of the team needs to be explored and

 ƒ oftware requirements operate on three levels: Business, Users

ƒ Identify a software product. (Ref: project list)

• Nguyen, Tam T. T. (2014). Requirements Engineering.

You might also like