Software requirements & specification

1-Introduction
Faculty of information technology
Fall 2020-2021

Prepared by: Dr. Mohamed Hagal

Instructor: Mr. Salah Abdelsattar
 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)