Professional Documents
Culture Documents
Software Requirement Engineering
Software Requirement Engineering
Engineering
Books
•System requirements
• setting out detailed descriptions of the system’s
functions, services and operational constraints.
Defines what should be implemented so may be
part of a contract between client and contractor.
User and system requirements
Functional requirements and non Functional
Requirements
• Functional requirements
• 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.
• Functional requirements often are written in the form of the
traditional “shall” statements:
• “The Passenger shall be able to print boarding passes for all flight
segments for which he has checked in”
• Nonfunctional requirement
• A description of a property or characteristic that a system must
exhibit or a constraint that it must respect.
• Constraint is a restriction that is imposed on the choices available to
the developer for the design and construction of a 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.
• Web browser bookmarks, spelling checkers,
automatic virus signature updating in an anti-
malware product are examples of features
• A feature can encompass multiple user
requirements, each of which implies that certain
functional requirements must be implemented to
allow the user to perform the task described by
each user requirement.
Relationships among features, user requirements, and functional requirements
Users of requirements documents
• System customers
• specify the requirements and read them to check they
meet their needs
• Project managers
• Use the requirements document to plan a bid for system
and to plan the system development process
• System engineers
• Use the requirements to understand the system being
developed
• System test engineers
• Use the requirements to develop validation tests for the
system
• System maintenance engineers
• Use the requirements to help understand the system
Sign-Off
• Ambiguous Requirements
• a reader can interpret a requirement statement in several ways
• Ambiguity also results from imprecise and insufficiently detailed
requirements that force developers to fill in the blanks.
• Ambiguous requirements result in wasted time when developers
implement a solution for the wrong problem.
• Testers who expect the product to behave differently from what
the developers intended waste time resolving the differences.
Requirements risks
• Minimal Specification
• Sometimes marketing staff or managers are tempted to
create a limited specification
• They expect the developers to expand the spec while the
project progresses
• This might work for a tightly integrated team that's building
a small system
• In most cases, though, it frustrates the developers and
disappoints the customers