Software requirements &

specification

1-Introduction
Faculty of information technology

Fall 2019-2020

Dr. Mohamed Hagal

 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
 Characteristics of Excellent Requirements
• Complete
Each requirement must fully describe the functionality to be delivered. It must contain all the
information necessary for the developer to design and implement that bit of functionality.

• Correct
Each requirement must accurately describe the functionality to be built.. Only user
representatives can determine the correctness of user requirements, which is why users or
their close surrogates (‫نائب‬/‫ )وكيل‬must review the requirements.

• Feasible
It must be possible to implement each requirement within the known capabilities and
limitations of the system and its operating environment.

• Necessary
Each requirement should document a capability that the customers really need. Every
requirement should originate from a source that has the authority to specify requirements.
Trace each requirement back to specific voice-of-the-customer input, such as a use case, a
business rule.
 Characteristics of Excellent Requirements

• Prioritized
Assign an implementation priority to each functional requirement to indicate how
essential it is.

• Unambiguous
All readers of a requirement statement should arrive at a single, consistent
interpretation of it, but natural language is highly prone to ambiguity. Write
requirements in simple, concise, straightforward language appropriate to the user
domain. Readers must be able to understand what each requirement is saying.
Define all specialized terms and terms that might confuse readers in a glossary

• Verifiable
See whether you can devise a few tests or use other verification approaches, such
as inspection. Requirements that are incomplete, inconsistent, infeasible, or
ambiguous are also unverifiable
 Requirements Analyst Role

• The requirements analyst is the individual who has the primary responsibility to
gather, analyze, document, and validate the needs of the project stakeholders. The
analyst serves as the principal conduit through which requirements flow between
the customer community and the software development team.

• Requirements analyst is a project role, not necessarily a job title. One or more
dedicated specialists could perform the role, or it could be assigned to team
members who also have other job functions. Regardless of their other project
responsibilities, analysts must have the skills, knowledge, and personality to
perform the analyst role well.

• The Analyst's Tasks

The analyst is a communication middleman, bridging the gap between vague
customer notions and the clear specifications that guide the software team's work.
The analyst must first understand the users' goals for the new system and then
define functional and quality requirements that allow project managers to
estimate, developers to design and build, and testers to verify the product.
Some of the typical activities the analyst might perform:

• *Define business requirements. Your work as an analyst begins when you help
the business or funding sponsor, product manager, or marketing manager define
the project's business requirements. Perhaps the first question to ask is, "Why are
we undertaking(‫ )نتعهد‬this project?" Business requirements include a statement of
the organization's business objectives and the ultimate vision of what the system
will be and do.
• *Elicit requirements. Requirements for a software product don't just waiting for
someone wearing(‫ )معدة‬a hat labelled "analyst" to collect them. A proactive analyst
helps users articulate(‫ )يبين‬the system capabilities they need to meet their business
objectives. The following are some of the gathering techniques:
– Interviews
– Document analysis
– Questionnaires
– Customer site visits
– Business process analysis
– Prototyping
– Reverse engineering of existing systems
Some of the typical activities the analyst might perform contd...
• Analyze requirements. Look for derived requirements that requested by the customers and for
unstated requirements that the customers seem to expect. Spot (‫ )أكتشف‬the vague, weak words that
cause ambiguity. Point out(‫ )أشر إلى‬conflicting requirements and areas that need more detail.
Specify the functional requirements at a level of detail suitable for use by the developers who will
implement them.

• Write requirements specifications. Requirements development leads to a shared understanding of

a system that will address(‫ )يعالج‬the customer's problem. The analyst is responsible for writing well-
organized specifications that clearly express this shared understanding.

• Lead(‫ )يثبت‬requirements validation. The analyst must ensure that requirement statements will
satisfy user needs. Analysts are central participants in reviews of requirements documents. They
should also review designs, code, and test cases that were derived from the requirements
specifications to ensure that the requirements were interpreted correctly.

• Manage requirements. A requirements analyst is involved throughout(‫ )كافة أنحاء‬the entire (‫)كامل‬
software development life cycle, so he should help in creation, reviewing, and executing the
project's requirements management plan.
 Sources of Requirements
The Following are several typical sources of software requirements:
• Interviews and discussions with potential users
• Documents that describe current or competing(‫ )يشترك معها‬products.
Documents can also describe regulations, laws etc. with which the product
must comply.
• System requirements specifications A product that contains both hardware
and software has a high-level system requirements specification that describes
the overall product. A portion of the system requirements is allocated to each
software subsystem. The analyst can derive additional detailed software
functional requirements from those allocated system requirements.
• Problem reports and enhancement requests for a current system.
Understanding the problems that users encounter with the current system and
hear ideas from users for improving the system in the next release.
• User questionnaires Surveys can collect a large amount of data from the
potential users.
• User questionnaires Surveys can collect a large amount of data from the
potential users.
• Observing users at work During a "day in the life" study.
• Scenario analysis of user tasks By identifying tasks that users need to
accomplish with the system ( such as use cases)