Please enable JavaScript.
Coggle requires JavaScript to display documents.
Chapter 1 - The essential of software requirement (Objectives of chapter,…
Chapter 1 -
The essential of software requirement
Objectives of chapter
Distinguish
product requirements
from
project requirements
Distinguish
requirements development
from
requirements management
.
Understand some
key terms
used in the software requirements domain
Be alert to several
requirements-related problems
that can arise
Software requirements defined
Some interpretations of requirement
Brian Lawrance
“anything that drives design choices”
Ian Sommerville
Requirements are a specification of what should be implemented. They are descriptions of how the system should behave, or of a system property or attribute.
They may be a constraint on the development process of the system.
The pure dictionary “requirement”
Software people do not use “requirement” in the same sense as a dictionary definition of the word: something demanded or obligatory, a need or necessity
Levels and types of requirements
Types of requirements
User requirement
What is it?
describe goals or tasks the users must be able to perform with the product that will provide value to someone
describe what the user will be able to do with the system
Domain
characteristics that are important to user satisfaction
descriptions of product attributes
Ways to represent user requirements
event-response tables
User Stories
Uses Cases
Example
a use case is
“Check in for a flight”
using an airline’s
website or a kiosk at the airport
Written as a user story, the same user requirement might read:
“As a passenger, I want to check in for a flight so I can board my airplane.”
Functional requirement
What is it?
specify the behaviors the product will exhibit under specific conditions
They describe what the developers must implement to enable users to accomplish their tasks (user requirements), thereby satisfying the business requirements
Example
“The Passenger shall be able to print boarding passes for all
flight segments for which he has checked in”
“If the Passenger’s profile does not indicate a seating
preference, the reservation system shall assign a seat.”
How are it written?
often are written in the form of the traditional “shall” statements
Where is it written?
9. software requirements specification (SRS)
What is it?
describes as fully as necessary the expected behavior of the software system
An SRS could be a report generated from information stored in a requirements management tool.
Where is it used in?
Testing
Quality Assurance
Development
Project Management
related project functions
Other names
functional spec
requirements document
business requirements document
other...
Bussiness requirement
What is it?
describe why the organization is implementing the system—the business benefits the organization hopes to achieve. The focus is on the business objectives of the organization or the customer who requests the system.
Who is it propounded?
the acquiring customer
the manager of the actual users
the funding sponsor for a project
the marketing department
a product visionary
Where is it recored ?
Vision and scope document
System Requirement
What is it?
describe the requirements for a product that is composed of multiple components or subsystems
Some people use the term “system requirements” to mean the detailed requirements for a software system, but that’s not how we use the term in this book.
A top-level requirement for a product that contains multiple subsystems, which could be all software or software and hardware.
system
A “system” in this sense is not just any information
system
A system can be all software or it can include both software and hardware subsystems.
People and processes are part of a system,
example
the cashier’s workstation in a supermarket
Bussiness Rule
Include
government regulations
industry standards
corporate policies
computational algorithms
business rules are not themselves software requirements because they have an existence beyond the boundaries of any specific software application
A policy, guideline, standard, or regulation that defines or constrains some aspect of the business. Not a software requirement in itself, but the origin of several types of software requirements.
6.Quality attribute
are also known as
quality of service requirements
constraints
quality factors
and the “–ilities.”
What does it describe?
describe the product’s characteristics in various dimensions that are important either to users or to developers and maintainers
such as
performance
safety
availability
portability
7.External Interface
A description of a connection between a software system and a user, another software system, or a hardware device.
external interfaces between the system and the outside world
These include connections to other software systems, hardware
components, and users, as well as communication interfaces
constraints
Design and implementation constraints impose restrictions on the options available to the developer during construction of the product.
Feature
A feature consists of one or more logically related system capabilities that provide value to a user and are described by a set of functional requirements
A
feature can encompass multiple user requirements,
certain functional
requirements must be implemented to allow the user to perform the task described by each user
requirement
Working with three levels
User Requirement
Functional Requirement
Bussiness Requirement
Product
vs.
projec
t requirements
Product Requirements
So far we have been discussing requirements that describe properties of a software system to be built.
Let’s call those product requirements
Project Requirements
What is it?
These are project requirements but not product requirements.
Projects certainly do have other
expectations
and
deliverables
that are
not a part
of the software the team implements, but that are necessary to the successful completion of the project as a whole.
SRS
Contains
product requirements
it should not include
design or implementation details (other than known constraints)
test plans
project plans
or similar information
What does it includes?
Support documentation
Infrastructure changes needed in the operating environment
User documentation
Requirements and procedures for releasing the product, installing it in the operating environment, configuring it, and testing the installation.
Staff training needs
Requirements and procedures for transitioning from an old system to a new one
Physical resources the development team needs
Product certification and compliance requirements.
Revised policies, processes, organizational structures, and similar documents.
Sourcing, acquisition, and licensing of third-party software and hardware components.
Beta testing, manufacturing, packaging, marketing, and distribution requirements.
Customer service-level agreements.
Requirements for obtaining legal protection (patents, trademarks, or copyrights) for intellectual property related to the software.
When bad requirements happen to good people
Most common requirement risks
Ambiguous requirements
Gold plating
when a developer adds functionality that wasn’t in the requirements specification
but which the developer believes “the users are just going
to love.”
Creeping user requirement
Overlooked stakeholders
Inaccurate Plan
Insufficient user involvement
Benefits from a high-quality requirements process
Benefits
Lower enhancement costs.
Fewer miscommunications.
Fewer unnecessary and unused features.
Reduced scope creep.
Faster development and delivery.
Reduced project chaos.
Reduced development rework.
Higher customer and team member satisfaction.
Fewer defects in requirements and in the delivered product.
Products that do what they’re supposed to do.
2. Requirements development and management
(
Requirement Engineering
)
Requirement Development
Analysis
What is it?
Analyzing requirements involves reaching a richer and
more precise understanding
of each requirement and representing sets of requirements in multiple ways.
What does it includes?
Understanding
the relative importance of
quality attributes
Allocating
requirements to software components defined in the
system architecture
Deriving
functional requirements from other
requirements information
Negotiating
implementation priorities
Decomposing
high-level requirements into an appropriate level of detail
Identifying gaps
in
requirements
or
unnecessary requirements
as they relate to the defined
scope
Analyzing
the information received from users to distinguish their
task goals
from
functional requirements
,
quality expectations
,
business rules
,
suggested solutions
, and
other information
Specification
What is it?
Requirements specification involves
representing
and
storing
the collected requirements knowledge in a
persistent
and
well-organized
fashion.
What does it includes?
Translating
the collected user needs into written
requirements
and
diagrams suitable
for comprehension, review, and use by their intended audiences.
Elicitation
What is it?
Elicitation encompasses all of the activities involved with
discovering requirements
, such as interviews, workshops, document analysis, prototyping, and others.
What does it includes?
Learning
about the environment in which the new product will be used.
Working
with individuals who represent each user class to understand their functionality needs and their quality expectations
Understanding
user tasks and goals and the business objectives with which those tasks align.
Identifying
the product’s expected user classes and other stakeholders.
Validation
What is it?
Requirements validation
confirms
that you have the
correct set of requirements information
that will enable developers to build a solution that satisfies the business objectives.
What does it includes?
Reviewing
the
documented requirements
to correct any problems before the development group accepts them
Developing
acceptance tests and criteria to confirm that a product based on the requirements would meet customer needs and achieve the business objectives.
Requirement Management
What does it includes?
Defining
the requirements
baseline
, a snapshot in time that represents an agreed-upon, reviewed, and approved set of functional and nonfunctional requirements, often for a specific product release or development iteration
Evaluating
the impact of proposed requirements changes and incorporating approved changes into the project in a controlled way
Keeping
project plans current with the requirements as they evolve
Negotiating
new commitments based on the estimated impact of requirements changes
Defining
the relationships and dependencies that exist between requirements
Tracking
requirements status and change activity throughout the project
Tracing
individual requirements to their corresponding designs, source code, and tests