Review

■ 1- Name and Explain Type of Software Products

■ 2- Name and Explain Software Development Activities
■ 3- Name Development Phases
REQUIREMENT
ENGINEERING
Masoud Bahrah
Objective

Students must understand that requirement gathering is the

most critical phase in software development and knowing how
to do this task in a professional way .
Content
■ 1- What is Requirement
■ 2- What is Requirement Engineering
■ 3- Important of Requirement
■ 4- Level of Requirement
■ 5- Requirement Engineering Activities
■ 6- Requirement Gathering Techniques
■ 7- Conclusion
What is Requirement?
■ IEEE defines as:
■ 1. A condition or capability needed by user to solve a problem or achieve an
objective
What is Requirement Engineering
■ The requirements of a software project are the functions, features, and constraints
that need to be met by the final product. In other words, the requirements define
what the software should do, how it should look, and any conditions that must be
met for it to be considered successful

‫لینک مقاله بنده در مورد پروسه جمع‬ https://doi.org/10.58342/.v11i2.73

‫آوری نیازمندی ها‬
Role of Requirements
Importance of Requirement
■ Fred Brooks emphasizes the importance of requirement engineering
and writes:
■ “The hardest single part of building a software system is deciding
precisely what to build.
■ No other part of the work so destroy the system if done wrong.
■ No other part is more difficult to correct later.”
■ Correction at later on stages is so much costly .
Levels of Requirements
■ Business Requirements: Business requirements define the goals and
objectives of the organization that why this system is needed by the
business.
■ User Requirements: User requirements add further detail to the
business requirements. They are called user requirements because
they are written from a user’s perspective and the focus of user
requirement describe tasks the user must be able to accomplish in
order to fulfill the above stated business requirements.
Levels of Requirements
■ Functional Requirements: are what you want a system to do
■ Non-Functional Requirements: are restrictions on the types of
solutions that will meet the functional requirements. These are used
to describe external system interfaces, design and implementation
constraints etc.
Non-functional requirement play a significant role in the development
of the system. If not captured properly, the system may not fulfill some of
the basic business needs. If proper care is not taken, the system may
collapse.
Requirement Statement Characteristics
■ Complete - A requirement should be specified for all conditions that can occur.
■ Correct - Each requirement must accurately describe the functionality to be built.
■ Feasible - It must be possible to implement each requirement
■ Prioritized - Assign an implementation priority to each requirement.
■ Unambiguous - All readers of a requirement statement should arrive at a single,
consistent interpretation of it.
■
Ambiguous requirements
■ Multiple readers arrive at different understanding
■ 1- when the student does not get minimum marks send a
message to his/her parent .
How much is minimum?
■ 2- Well, I've certainly never tasted chicken cooked that way
before!
Was the chicken good or bad?
■ 3- Call me a taxi, please.
Is the speaker asking someone to hail them a taxi or to be
called a taxi?
Some Risks From Inadequate Requirement Process
■ Insufficient user involvement leads to unacceptable products
■ Ambiguous requirements lead to ill-spent time and rework.
■ Gold-plating by developers and users adds unnecessary features.
■ Minimal specifications lead to missing key requirements ( tool but no
print option)
■ ignoring the needs of certain user classes (stake holders) leads to
dissatisfied customers.
■ Incompletely defined requirements make accurate project planning
and tracking impossible.
Stake Holders
■ Stakeholders – different people who would be interested in the
software. Or, A person or Organization that may be effected by the
success or failure of a project
■
Requirement Gathering Technique

■ Many techniques are available for gathering requirements. Each has

value in certain circumstances, and in many cases, you need multiple
techniques to gain a complete picture from a diverse set of clients and
stakeholders.
■ 1- One-on-one interviews: The most common technique for gathering
requirements is to sit down with the clients and ask them what they
need. The discussion should be planned out ahead of time based on
the type of requirements you’re looking for. There are many good ways
to plan the interview, but generally you want to ask open-ended
questions to get the interviewee to start talking and then ask Detailed
questions to uncover requirements.
Requirement Gathering Technique

■ 2- Group interviews: Group interviews are similar to the one-

on-one interview, except that more than one person is being
interviewed — usually two to four. These interviews work well
when everyone is at the same level or has the same role.
■ 3- Joint application development (JAD): For a requirements
JAD session, the participants stay in session until a
complete set of requirements is documented and agreed to.
Requirement Gathering Technique

■ 4- Prototyping: Prototyping is a relatively modern technique for

gathering requirements. In this approach, you gather preliminary
requirements that you use to build an initial version of the solution — a
prototype. You show this to the client, who then gives you additional
requirements. You change the application and cycle around with the
client again, till client agree.
Requirement Gathering Technique

■ 5- Following people around: This technique is especially helpful when

gathering information on current processes. You may need to watch
them perform their job before you can understand the entire picture.
In some cases, you might also want to participate in the actual work
process to get a hands-on feel for how the business function works
today.
Requirement Gathering Technique

■ 6- Brainstorming: in some cases the solution is brand new and needs

to be created as a set of ideas that people can agree to. In this type of
project, simple brainstorming may be the starting point. The
appropriate subject matter experts get into a room and start creatively
brainstorming what the solution might look like. After all the ideas are
generated, the participants prioritize the ones they think are the best
for this solution.
User Problems / Claims
■ Users don’t understand what they want
■ Users won’t commit to a set of written requirements
■ Users need new requirements after the cost and schedule have been
fixed
■ Communication with users is slow and often ‘low’
■ Users often do not participate in reviews or are incapable of doing so
■ Users don’t understand the software development process
■ etc.
Conclusion
■ Requirement is what the software owner wants the system to do
■ Requirement gathering is risky and important phase of software
development , because wrong understand will let wrong creation .
■ You can use your Requirement Engineering knowledge to handle this
problem effectively .
Expected Outcome

■ Students know how important is Requirement Gathering and

correctness of Requirement .
■ Students can manage to do a proper requirement gathering session .
Class Activity – Role Playing

■ Suppose you got the contract for a new software system , how you
collect the requiring ?.
Question ???