CHAPTER 4

REQUIREMENT ANALYSIS & SPECIFICATION

Requirement Engineering Process

• Requirement Engineering means that requirements for a product are defined, managed and
tested systematically.
• Requirements engineering builds a bridge to design and construction.
• Requirements engineering provides the appropriate mechanism for understanding what the
customer wants, analyzing need, assessing feasibility, negotiating a reasonable solution,
specifying the solution unambiguously, validating the specification, and managing the
requirements as they are transformed into an operational system.

Requirement Engineering Tasks

• Inception
̶ Establish a basic understanding of the problem and the nature of the solution.
̶ In project inception, you 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
̶ Draw out the requirements from stakeholders.
̶ Number of problems that are encountered as elicitation occurs are problems of scope,
problems of understanding, problems of volatility
• Elaboration (Highly structured)
̶ Create an analysis model that represents information, functional, and behavioral
aspects of the requirements.
̶ Elaboration is driven by the creation and refinement of user scenarios that describe
how the end user (and other actors) will interact with the system.
̶ Each user scenario is parsed to extract analysis classes—business domain entities that
are visible to the end user.
̶ The attributes of each analysis class are defined, and the services that are required by
each class are identified.
̶ The relationships and collaboration between classes are identified, and a variety of
supplementary diagrams are produced.
• Negotiation
̶ Agree on a deliverable system that is realistic for developers and customers.
̶ The best negotiations strive for a “win-win” result.
̶ That is, stakeholders win by getting the system or product that satisfies the majority of
their needs and you (as a member of the software team) win by working to realistic
 and achievable budgets and deadlines.
̶ activities in negotiation are :
̶ Identification of the system or subsystem’s key stakeholders.
̶ Determination of the stakeholders’ “win conditions.”
̶ Negotiation of the stakeholders’ win conditions to reconcile them into a set of win-win
conditions for all concerned (including the software team).
• Specification
̶ Describe the requirements formally or informally.
̶ A specification can be a written document, a set of graphical models, a formal
mathematical model, and a collection of usage scenarios, a prototype, or any
combination of these.
• Validation
̶ Review the requirement specification for errors, ambiguities, omissions, and conflicts.
̶ Requirements validation examines the specification to ensure that all software
requirements have been stated unambiguously; that inconsistencies, omissions, 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.
̶ The primary requirements validation mechanism is the technical review.
̶ The review team that validates requirements includes software engineers, customers,
users, and other stakeholders who examine the specification looking for errors in
content or interpretation, areas where clarification may be required, missing
information, inconsistencies (a major problem when large products or systems are
engineered), conflicting requirements, or unrealistic (unachievable) requirements.
• Requirements management
̶ Manage changing requirements.
̶ 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 process.
̶ Many of these activities are identical to the software configuration management.

System Requirement Specification

• It contains a complete information description, a detailed functional description, a
representation of system behaviour, an indication of performance requirements and design
constraints, appropriate validation criteria, and other information pertinent to
requirements.
• Software requirement specification (SRS) is a document that completely describes what the
proposed software should do without describing how software will do it.
• The basic goal of the requirement phase is to produce the SRS, Which describes the
complete behaviour of the proposed software.
• SRS is also helping the clients to understand their own needs.
 Characteristics of an SRS
Software requirements specification should be accurate, complete, efficient, and of high
quality, so that it does not affect the entire project plan. An SRS is said to be of high quality
when the developer and user easily understand the prepared document. Other characteristics
of SRS are discussed below.
Correct
• SRS is correct when all user requirements are stated in the requirements document.
• The stated requirements should be according to the desired system.
• This implies that each requirement is examined to ensure that it (SRS) represents user
requirements.
• Note that there is no specified tool or procedure to assure the correctness of SRS.
Correctness ensures that all specified requirements are performed correctly.
Unambiguous
• SRS is unambiguous when every stated requirement has only one interpretation.
• This implies that each requirement is uniquely interpreted.
In case there is a term used with multiple meanings, the requirements document should specify the
meanings in the SRS so that it is clear and easy to understand

Complete
• SRS is complete when the requirements clearly define what the software is required to do.
• This includes all the requirements related to performance, design and functionality.
Ranked for importance/stability
• All requirements are not equally important, hence each requirement is identified to
make differences among other requirements.
• For this, it is essential to clearly identify each requirement. Stability implies the
probability of changes in the requirement in future.
Modifiable
• The requirements of the user can change, hence requirements document should be
created in such a manner that those changes can be modified easily, consistently
maintaining the structure and style of the SRS.
Traceable
• SRS is traceable when the source of each requirement is clear and facilitates the
reference of each requirement in future.
• For this, forward tracing and backward tracing are used.
• Forward tracing implies that each requirement should be traceable to design and code
elements.
• Backward tracing implies defining each requirement explicitly referencing its source.
Verifiable
• SRS is verifiable when the specified requirements can be verified with a cost-effective
process to check whether the final software meets those requirements.
• The requirements are verified with the help of reviews. Note that unambiguity is
essential for verifiability.
Consistent
• SRS is consistent when the subsets of individual requirements defined do not conflict
with each other.
• For example, there can be a case when different requirements can use different terms
to refer to the same object.
• There can be logical or temporal conflicts between the specified requirements and
some requirements whose logical or temporal characteristics are not satisfied.
• For instance, a requirement states that an event 'a' is to occur before another event 'b'.
But then another set of requirements states (directly or indirectly by transitivity) that
event 'b' should occur before event 'a'.

Functional and Non-Functional Requirements

Functional requirements
• These describe the functionality of a system -- how a system should react to a particular set
of inputs and what should be the corresponding output.
• Given a problem statement, the functional requirements could be identified by focusing on
the following points:
̶ Identify the high level functional requirements simply from the conceptual
understanding of the problem. For example, a Library Management System, apart
from anything else, should be able to issue and return books.
̶ Identify the cases where an end user gets some meaningful work done by using the
system. For example, in a digital library a user might use the "Search Book"
functionality to obtain information about the books of his interest.
̶ If we consider the system as a black box, there would be some inputs to it, and some
output in return. This black box defines the functionalities of the system. For example,
to search for a book, user gives title of the book as input and get the book details and
location as the output.
̶ Any high level requirement identified could have different sub-requirements. For
example, "Issue Book" module could behave differently for different class of users, or
for a particular user who has issued the book thrice consecutively.
Non-Functional requirements
• They are not directly related what functionalities are expected from the system.
• However, NFRs could typically define how the system should behave under certain situations.
• For example, a NFR could say that the system should work with 128MB RAM.

Example:
Functional Requirements for Hotel Management System
1. Reservation/Booking
1.1. The system shall record reservations.
1.2. The system shall record the customer’s first name.
1.3. The system shall record the customer’s last name.
1.4. The system shall record the number of occupants.
1.5. The system shall record the room number.
1.6. The system shall display the default room rate.
1.7. The system shall record the customer’s phone number.
1.8. The system shall display whether or not the room is guaranteed.
1.9. The system shall generate a unique confirmation number for each reservation.
1.10. The system shall record the expected check-in date and time.
1.11. The system shall record the expected checkout date and time.
1.12. The system shall check-in customers.
1.13. The system shall allow reservations to be modified without having to reenter
all the customer information.
1.14. The system shall checkout customers.
1.15. The system shall charge the customer for an extra night if they checkout after 11:00 a.m.
1.16. The system shall mark guaranteed rooms as “must pay” after 6:00 pm on the
check-in date.
1.17. The system shall record customer feedback.
2. Food
2.1. The system shall track all meals purchased in the hotel (restaurant and room service).
2.2. The system shall record payment and payment type for meals.
2.3. The system shall bill the current room if payment is not made at time of service.
2.4. The system shall accept reservations for the restaurant and room service.
3. Management
3.1. The system shall display the hotel occupancy for a specified period of time
(days; including past, present, and future dates).
3.2. The system shall display projected occupancy for a period of time (days).
3.3. The system shall display room revenue for a specified period of time (days).
3.4. The system shall display food revenue for a specified period of time (days).
3.5. The system shall display an exception report, showing where default room and
food prices have been overridden.
3.6. The system shall allow for the addition of information, regarding rooms, rates,
menu items, prices, and user profiles.
3.7. The system shall allow for the deletion of information, regarding rooms, rates,
menu items, prices, and user profiles.
3.8. The system shall allow for the modification of information, regarding rooms,
rates, menu items, prices, and user profiles.
3.9. The system shall allow managers to assign user passwords.

Non-Functional Requirements for Hotel Management System

1 The load time for user interface screens shall take no longer than two seconds.
2 The log in information shall be verified within five seconds.
3 Queries shall return results within five seconds.
4 The Hotel Management System shall be a stand-alone system running in a Windows environment.
5 The system shall be developed using Java platform.
6 There shall be consistency in variable names within the system.
7 The graphical user interface shall have a consistent look and feel.
8 Specify the factors required to establish the required reliability of the software
system at time of delivery.
9 The system shall be available during normal hotel operating hours.
10 Customer Service Representatives and Managers will be able to log in to the Hotel
Management System. Customer Service Representatives will have access to the
Reservation/Booking and Food subsystems. Managers will have access to the Management
subsystem as well as the Reservation/Booking and Food subsystems.
11 Access to the various subsystems will be protected by a user log in screen that requires a
user name and password.