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.
 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
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 identifies three types of requirements :
• Normal requirements. The objectives and goals that are stated for a product
or system 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.
• Customer determine 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
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

1.Introduction 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
2.The 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.