REQUIREMENTS ENGINEERING

• The Hardest part of developing a software is deciding precisely what is to be

developed.
• Requirement engineering is the disciplined application of proven principle, methods,
tools, and notations to describe a proposed system’s intended behavior and its
associated constraints.
This image humorously shows how miscommunication in software projects can
lead to very different outcomes at each stage from customer needs to final delivery.

Every team member (customer, project leader, analyst, programmer, etc.) interprets
the same idea differently, resulting in a product that doesn’t meet the real need.

Example:
A customer asks for a “swing on a tree.”
•The analyst designs a complex system.
•The programmer builds something functional but odd.
•The tester documents an empty tree.
•The final delivery is nothing like what the customer truly wanted a simple tire swing.

Note:
Clear communication, requirement analysis, and continuous feedback are essential
to build what the customer actually needs, not just what they say.
 DIFFICULTIES IN REQUIREMENT ENGG.

1. No one give you complete requirement in the first time, if someone does then also
requirement are incomplete.
2. Requirements get added and changed as the user begins to understand the system
and his real need
3. Insufficient time to do a decent job
4. Communication barrier (Different technical backgrounds)
5. Lack of resources
6. Developer want more precise definition while user prefer natural language
 TYPES OF REQUIREMENT

1. Known Requirement
2. Unknown Requirement
3. Undreamt Requirement
•Feasibility Study
•The process begins with assessing whether the project is feasible in terms of cost, technology, and
time.
•Feasibility Report
•After conducting the feasibility study, a report is generated to present findings and
recommendations.
•Requirements Elicitation and Analysis
•This step focuses on gathering all requirements through meetings with stakeholders, analyzing
existing processes, etc.
•System Models
•After analyzing the requirements, the system models are created to represent the system
architecture and functionality.
•User and System Requirements
•Identifying and documenting both user requirements (what the end users need) and system
requirements (what the system must do technically).
•Requirements Specification
•This is the formal documentation of the requirements, detailing what the system will do.
•Requirements Validation
•Ensuring that the specified requirements align with what stakeholders need and that they are
feasible to implement.
•Requirements Document
•The final document that consolidates all the requirements and system specifications is created for
approval and further use in system development.
REQUIREMENTS ENGINEERING

• Requirements analysis, also called requirements engineering, is the

process of determining user expectations for a new or modified
product.
• Requirements engineering is a major software engineering action that
begins during the communication activity and continues into the
modeling activity.
• It encompasses seven distinct tasks: inception, elicitation,
elaboration, negotiation, specification, validation, and management.
• Inception :
• It establish a basic understanding of the problem, the people who want a solution,
the nature of the solution that is desired, and the effectiveness of preliminary
communication and collaboration between the other stakeholders and the
software team.
• Elicitation:
• In this stage, proper information is extracted to prepare the document for the
requirements.
• It certainly seems simple enough—ask the customer, the users, and others what
the objectives for the system or product are, what is to be accomplished, how the
system or product fits into the needs of the business, and finally, how the system
or product is to be used on a day to day basis.
• Elaboration:
• The information obtained from the customer during inception and elicitation is
expanded and refined during elaboration. This task focuses on developing a
refined requirements model that identifies various aspects of software function,
behavior, and information.
• Negotiation:
• To negotiate the requirements of a system to be developed, it is necessary to
identify conflicts and to resolve those conflicts. You have to reconcile these
conflicts through a process of negotiation.
• Specification:
• The term specification means different things to different people. A
specification can be a written document, a set of graphical models, a formal
mathematical model, a collection of usage scenarios, a prototype, or any
combination of these.
• Validation:
• The work products produced as a consequence of requirements engineering
are assessed for quality during a validation step.
• Requirements validation examines the specification to ensure that all
software requirements have been stated unambiguously; that inconsistencies,
and errors have been detected and corrected; and that the work products
conform to the standards established for the process, the project, and the
product.
• Requirements management.
• Requirements for computer-based systems change, and the desire to change
requirements persists throughout the life of the system.
• Requirements management is a set of activities that help the project team
identify, control, and track requirements and changes to requirements at any
time as the project proceeds.
ESTABLISHING THE GROUNDWORK
• Identifying Stakeholders
• A stakeholder is anyone who has a direct interest in or benefits from the
system that is to be developed. At inception, you should create a list of people
who will contribute input as requirements are elicited.
• Recognizing Multiple Viewpoints
• Because many different stakeholders exist, the requirements of the system
will be explored from many different points of view. The information from
multiple viewpoints is collected, emerging requirements may be inconsistent
or may conflict with one another.
• Working toward Collaboration
• The job of a requirements engineer is to identify areas of commonality and
areas of conflict or inconsistency.
ELICITING REQUIREMENTS
• Elicitation: the process of getting or producing something, especially
information or a reaction
• It is most difficult, most critical, most error-prone, and communication intensive
aspect of the software development.
• Requirements elicitation (also called requirements gathering) combines elements
of problem solving, elaboration, negotiation, and specification
• Collaborative Requirements Gathering
• Many different approaches to collaborative requirements gathering have
been proposed.
• During inception basic questions and answers establish the scope of the
problem and the overall perception of a solution. Out of these initial
meetings, the developer and customers write a one- or two-page “product
request.”
Approach

• Interview (Structure/ unstructured, Open ended, agenda based)

• Brain Storming (Group discussion)
• Delphi technique (Written correspondence exchanged among the participants)
• FAST (Facilitated application specification technique)
• Everyone will prepare a list of
• What surrounds the system
• Produced by the system
• Used by the system
• List of services, constraints, and performance criterion
• Then divide list into smaller list to work in smaller teams
• Quality Function Deployment
• Quality function deployment (QFD) is a quality management technique that
translates the needs of the customer into technical requirements for
software.
• QFD “concentrates on maximizing customer satisfaction from the software
engineering process”.
• To accomplish this, QFD emphasizes an understanding of what is valuable to
the customer and then deploys these values throughout the engineering
process.
• Although QFD concepts can be applied across the entire software process,
QFD uses customer interviews and observation, surveys, and examination of
historical data as raw data for the requirements gathering activity.
• These data are then translated into a table of requirements— called the
customer voice table—that is reviewed with the customer and other
stakeholders.
• QFD(Quality Function Deployment) identifies three types of requirements :
• Normal requirements. The objectives and goals that are stated for a product or
system are discussed during meetings with the customer. If these requirements are
present, the customer is satisfied. Examples of normal requirements might be
requested types of graphical displays, specific system functions, and defined levels of
performance.
• Expected requirements. These requirements are implicit to the product or system
and may be so fundamental that the customer does not explicitly state them. Their
absence will be a cause for significant dissatisfaction.
• Exciting requirements. These features go beyond the customer’s expectations and
prove to be very satisfying when present.
• The customer determines the importance of each requirement on a scale of 1 to 5:
• 5 – Very important
• 4 – Important
• 3 – Not important, but Nice to have
• 2 – Not important
• 1 – Unrealistic
Elicitation and Analysis Process diagram:
[Link] Entry
•The process begins with the entry point, where the gathering of requirements starts.
[Link] Understanding
•This stage involves understanding the context, background, and constraints of the domain in which the
system is being developed.
[Link] Collection
•At this step, all relevant requirements are gathered from stakeholders, ensuring a comprehensive set of
inputs.
[Link]
•The collected requirements are classified into categories to facilitate better management and
understanding.
[Link]
•Requirements are prioritized based on their importance, urgency, and impact on the project.
[Link] Resolution
•Conflicts that arise from differing stakeholder needs are resolved to ensure alignment across the
project.
[Link] Validation
•The requirements are validated to ensure they are complete, correct, and feasible.
[Link] Definition and Specification
•Finally, the validated requirements are defined in detail, documented, and specified for further use in
the development process.
Requirement Analysis

• In this phase we analyze the set of requirements to find any inconsistency or

conflicts.
• Check How many requirements are contradictory to each other or requires further
exploration.
• Different tools can be used like DFD, ER diagram, use cases.
Requirement Documentation
• After have final set of requirements, it is also necessary to document
in a standard format, so that it can be understood easily even by non-
technical person. E.g. Mark sheet, balance sheet, research papers.
• IEEE provides standard for SRS documents in IEEE830, using which we
make SRS document more readable, modifiable, and a format which
can be followed through the world.
 IEEE STANDARDS FOR SRS

[Link] 3. Specific Requirements

1. Purpose 1. External Interfaces
2. Scope 2. Functions
3. Definition, Acronyms and abbreviations 3. Performance requirements
4. References 4. Logical database requirements
5. Overview 5. Design Constraints
[Link] Overall Description 6. Software System attributes
2.1 Product Perspective 7. Organization of specific requirements
1. System Interfaces 8. Additional Comments.
2. Interfaces
3. Hardware Interfaces 4. Change Management Process
4. Software Interfaces 5. Document Approval
5. Communication Interfaces 5.1 Table, Diagram, and flowchart
6. Memory Constraints 5.2 Appendices
7. Operations 5.3 Index
8. Site Adaptation Requirements
2.2 Product Functions
2.3 User Characteristics
2.4 Constraints
2.5 Assumptions for dependencies
2.6 Apportioning of requirements
SRS document

• The important parts of SRS document are:

• Functional requirements of the system
• Non-functional requirements of the system, and
• Goals of implementation
Functional requirements:-
• Requirement, which are related to Functional/working aspect of
software fall into this category.
• The functional requirements discusses the functionalities required
from the system.
• The system is considered to perform a set of high-level functions {fi}.
• Each function fi of the system can be considered as a transformation
of a set of input data (I) to the corresponding set of output data (O).
The user can get some meaningful piece of work done using a high-
level function.
Nonfunctional requirements:-
• Nonfunctional requirements deal with the characteristics of the
system which can not be expressed as functions - such as the
maintainability of the system, portability of the system, usability of
the system, security, cost, disaster management, etc.
• Nonfunctional requirements may include:
• # reliability issues, # accuracy of results,
• # human - computer interface issues,
• # constraints on the system implementation, etc.
Goals of implementation:-

• The goals of implementation part documents some general

suggestions regarding development. These suggestions guide trade-
off among design goals.
• The goals of implementation section might document issues such as
revisions to the system functionalities that may be required in the
future, new devices to be supported in the future, reusability issues,
etc.
• These are the items which the developers might keep in their mind
during development so that the developed system may meet some
aspects that are not required immediately.
Example: - Withdraw Cash from ATM
• R1: withdraw cash
• Description: The withdraw cash function first determines the type of
account that the user has and the account number from which the
user wishes to withdraw cash. It checks the balance to determine
whether the requested amount is available in the account. If enough
balance is available, it outputs the required cash, otherwise it
generates an error message.
• R1.1 select withdraw amount option
• Input: “withdraw amount” option
• Output: user prompted to enter the account type
• R1.2: select account type
• Input: user option
• Output: prompt to enter amount
• R1.3: get required amount
• Input: amount to be withdrawn in integer values greater than 100 and
less than 10,000 in multiples of 100.
• Output: The requested cash and printed transaction statement.
• Processing: the amount is debited from the user’s account if sufficient
balance is available, otherwise an error message displayed.
Properties of a good SRS document
• Concise. The SRS document should be concise and at the same time
unambiguous, consistent, and complete. Verbose and irrelevant
descriptions reduce readability and also increase error possibilities.
• Structured. It should be well-structured. A well-structured document
is easy to understand and modify. In practice, the SRS document
undergoes several revisions to cope up with the customer
requirements. Often, the customer requirements evolve over a period
of time. Therefore, in order to make the modifications to the SRS
document easy, it is important to make the document well-
structured.
• Conceptual integrity. It should show conceptual integrity so that the
reader can easily understand it.
• Response to undesired events. It should characterize acceptable
responses to undesired events. These are called system response to
exceptional conditions.
• Black-box view. It should only specify what the system should do and
refrain from stating how to do these. This means that the SRS
document should specify the external behavior of the system and not
discuss the implementation issues. The SRS document should view
the system to be developed as black box, and should specify the
externally visible behavior of the system. For this reason, the SRS
document is also called the black-box specification of a system.
• Verifiable. All requirements of the system as documented in the SRS
document should be verifiable. This means that it should be possible
to determine whether or not requirements have been met in an
implementation.
Decision tree
• A decision tree gives a graphic view of the processing logic involved in
decision making and the corresponding actions taken. The edges of a
decision tree represent conditions and the leaf nodes represent the
actions to be performed depending on the outcome of testing the
condition.
• Example: - Consider Library Membership Automation Software (LMS)
where it should support the following three options:
• New member
• Renewal
• Cancel membership
• New member option
• Decision: When the 'new member' option is selected, the software asks details about
the member like the member's name, address, phone number etc.
• Action: If proper information is entered then a membership record for the member is
created and a bill is printed for the annual membership charge plus the security deposit
payable.
• Renewal option
• Decision: If the 'renewal' option is chosen, the LMS asks for the member's name and
his membership number to check whether he is a valid member or not.
• Action: If the membership is valid then membership expiry date is updated and the
annual membership bill is printed, otherwise an error message is displayed.
• Cancel membership option
• Decision: If the 'cancel membership' option is selected, then the software asks for
member's name and his membership number.
• Action: The membership is cancelled, a cheque for the balance amount due to the
member is printed and finally the membership record is deleted from the database.
Decision table
• A decision table is used to represent the complex processing logic in a
tabular or a matrix form.
• The upper rows of the table specify the variables or conditions to be
evaluated.
• The lower rows of the table specify the actions to be taken when the
corresponding conditions are satisfied.
• A column in a table is called a rule. A rule implies that if a condition is
true, then the corresponding action is to be executed.