Software requirements & specification

1-Introduction
Faculty of information technology
Fall 2020-2021

Prepared by: Dr. Mohamed Hagal

Instructor: Mr. Salah Abdelsattar
 Introduction

The IEEE Standard Glossary of Software Engineering

Terminology (1990) defines a requirement as

•A condition or capability needed by a user to solve a

problem or achieve an objective.

•A condition or capability that must be met or

possessed by a system or system component to satisfy
a contract, standard, specification, or other formally
imposed document.
 Levels of requirements

Software requirements include three distinct

Levels:

• business requirements
• user requirements
• functional requirements.
• Business requirements represent high-level objectives of the organization
or customer who requests the system. They describe why the organization
is implementing the system—the objectives the organization hopes to
achieve.

• User requirements describe user goals or tasks that the users must be
able to perform with the product. Valuable ways to represent user
requirements include use cases, scenario descriptions, etc. User
requirements therefore describe what the user will be able to do with the
system. An example of a use case is "Make a Reservation" using an airline,
a rental car, or a hotel Web site.

The user requirements permit the analyst to derive the bits of

functionality that will let the users perform their tasks with the product.

• Functional requirements specify the software functionality that the

developers must build into the product to enable users to accomplish their
tasks, thereby satisfying the business requirements. Sometimes called
behavioral requirements.
 The Feature
• People often talk about product features.
• A feature is a set of logically related functional
requirements that provides a capability to the
user and enables the satisfaction of a business
objective. In the commercial software area, a
feature is a group of requirements
recognizable to a stakeholder that aids in
making a purchase decision.
 What Requirements Are Not

• Requirements specifications do not include

design or implementation details, project
planning information, or testing information.

• Separate such items from the requirements so

that the requirements activities can focus on
understanding what the team intends to build.
 Some of the most common requirements risks are
• Insufficient User Involvement
Customers often don't understand why it is so essential to work hard on gathering requirements, and they
think they already know what the users need. Insufficient user involvement leads to late-breaking
requirements that delay project completion.

• Creeping User Requirements

As requirements evolve and grow during development, projects often exceed their planned schedules and
budgets. Such plans aren't always based on realistic understandings of the size and complexity of the
requirements.

To manage scope creep, begin with a clear statement of the project's business objectives, strategic vision,
scope, limitations, success criteria and expected product usage. Evaluate all proposed new features or
requirements changes against this reference framework.

Added code can cause modules to violate the solid design principles of strong cohesion and loose
coupling. To minimize this,, flow requirements changes through the architecture and design rather than
implementing them directly into code.

• Ambiguous Requirements
Ambiguity is the great bugaboo of requirements specifications. One symptom of ambiguity is that a reader
can interpret a requirement statement in several ways. Another sign is that multiple readers of a
requirement arrive at different understandings of what it means. Ambiguity also results from imprecise
and insufficiently detailed requirements.

Ambiguous requirements result in wasted time when developers implement a solution for the wrong
problem.

Writing test cases against the requirements and building prototypes are other ways to discover
ambiguities.
• Gold Plating
Gold plating takes place when a developer adds functionality that wasn't in the requirements specification
but that the developer believes "the users are just going to love." Often users don't care about this excess
functionality, and the time spent implementing it is wasted. Rather than simply inserting new features,
developers and analysts should present the customers with creative ideas and alternatives for their
consideration. Developers should not going beyond what the customer requests without customer
approval.

• Customers sometimes request features or elaborate user interfaces that look cool but add little value to
the product. Everything you build costs time and money. To reduce the threat of gold plating, trace each
bit of functionality back to its origin so that you know why it's included. The use-case approach for eliciting
requirements helps to focus requirements elicitation on the functionality that lets users perform their
business tasks.

• Minimal Specification
Sometimes marketing staff or managers are tempted to create a limited specification. In most cases,
though, it frustrates the developers (who might be operating under incorrect assumptions and with
limited direction) and disappoints the customers (who don't get the product they envisioned).

• Overlooked User Classes

Most products have several groups of users might have varying experience levels. If you don't identify the
important user classes for your product early o n, some user needs won't be met.

• Inaccurate Planning
The top contributors to poor software cost estimation are frequent requirements changes, missing
requirements, insufficient communication with users, poor specification of requirements, and insufficient
requirements analysis. When you present an estimate, provide either a range (best case, most likely, worst
case) or a confidence level ("I'm 90 percent sure I can have that done within three months").
 Benefits from a High-Quality Requirements Process

• Organizations that implement effective requirements engineering processes can reap (‫)ﺗﺟﻧﻲ‬
multiple benefits. A great reward comes from reducing unnecessary rework during the late
development stages and throughout the lengthy maintenance period.

• Customer involvement reduces the expectation gap between what the user needs and what the
developer delivers. You're going to get the customer feedback eventually. Try to get it early rather
than late, perhaps with the help of prototypes that stimulate user feedback.

• An effective change-control process will minimize the adverse impact of requirements changes.
Documented, unambiguous requirements greatly facilitate system testing, which in turn increases
your chances of delivering high-quality products that satisfy all stakeholders.

• It's impossible to quantify(‫ )ﻧﻘدر أو ﻧﻘﯾس‬all the following benefits, but they are real:
– Fewer requirements defects
– Reduced development rework
– Lower enhancement costs
– Faster development
– Fewer miscommunications
– Reduced scope creep
– Reduced project chaos (‫)ﻓوﺿﻰ‬
– More accurate system-testing estimates
– Higher customer and team member satisfaction