info 627lecture #61 requirements engineering and management info 627 refining the system definition...
Post on 21-Dec-2015
214 views
TRANSCRIPT
INFO 627 Lecture #6 1
Requirements Engineeringand ManagementINFO 627
Refining the System Definition
Glenn Booker
INFO 627 Lecture #6 2
Requirements Now that we have a good idea of the
customer needs, have defined the main features for our system, and selected a structure for managing the implementation of those features…*whew*
We can now work on refining requirements to guide development and testing
INFO 627 Lecture #6 3
Requirements As we define and refine requirements, it must
be clear that the written description of those requirements is the only authority as to what we are creating
And changes in scope or intent need to be reflected immediately
We started by defining features vaguely – now we add details
INFO 627 Lecture #6 4
Requirements The system must fulfill user needs The system requirements must be complete
and consistent, and fit in the environment where it will live
Definition of requirements also supports detailed feasibility study, to ensure we are making a wise investment
INFO 627 Lecture #6 5
Requirements How precise requirements need to be depends
on the type of application and the industry it supports We hope that aircraft flight control software is
designed more carefully than Microsoft Word Goal is to produce understandable
requirements to support meeting user needs
INFO 627 Lecture #6 6
Requirements Many methods or models can be used
to express requirements Use Cases Natural language Formal methods (Z or Larch)
Storage and management of those requirements could be in a spreadsheet or database
INFO 627 Lecture #6 7
Requirements Requirements need to be:
Understood by all parties concerned Specific enough to be verified
and demonstrated From the beginning, think of requirements in
terms of being able to prove whether they have been fulfilled (“Trust but verify”)
INFO 627 Lecture #6 8
Software Requirements Software requirements are generally related to
some capability the user needs to have, or some capability the systems needs for some other reason
Inputs and outputs are good places to start looking for requirements
Don’t forget non-functional requirements!
INFO 627 Lecture #6 9
Software Requirements Think of the system as a black box, and focus
on what needs to go into and leave the system Five major classes of things can describe a
system (per Davis) Inputs to the system, in terms of content, format,
and source
INFO 627 Lecture #6 10
Software Requirements Outputs from the system, including the type of
output device, and format of the outputs Functions of the system, to accept inputs and/or
create outputs Attributes of the system, such as the “–ilities”,
throughput, and performance Attributes of the system environment, such
as where it is used, and compatibility with other systems
INFO 627 Lecture #6 11
Software Requirements Using this kind of breakdown helps
ensure completeness of requirements Also can use these categories to
help determine if something really is a requirement
Features lead to one or more requirements So requirements help to define the scope
and exact capabilities of features
INFO 627 Lecture #6 12
Mapping Features to Requirements We need to trace the origin of requirements
from their corresponding features This traceability helps ensure we define
complete requirements All features result in one or more requirements [Side note: Microsoft products don’t recognize
“traceability” as a word…does that tell us something about their products?]
1E p. 231
INFO 627 Lecture #6 13
What Requirements Are Not The challenge in writing requirements
is to avoid things which shouldn’t impersonate requirements Project management information Unneeded design or implementation details Testing information
Requirements should focus on system behavior, not its inner workings
INFO 627 Lecture #6 14
Project Management Information Requirements should not include
Budget, staffing, or schedule information Configuration management plans Testing plans (except maybe hints for very
unusual cases) Put these in separate Program Management
Plan, CM Plan, etc.
INFO 627 Lecture #6 15
Unneeded Design Details Do not define the system design or
architecture as requirements Reduces the creativity of the developers
to use an even better approach Includes specifying development language, tools,
design methodology (e.g. OO vs. relational database)
INFO 627 Lecture #6 16
Design Constraints If an aspect of the system design is artificially
constrained BY THE CUSTOMER, make it a design constraint Only if the customer mandated it
Other design decisions should only appear in design documents, not hiding among requirements E.g. if using VB is the best language
INFO 627 Lecture #6 17
Testing Plans Requirements do not include
Test plans Verification and validation plans Test cases
In very rare cases, a testing approach may be hinted at or suggested if a suitable approach may not be obvious
INFO 627 Lecture #6 18
Implied Requirement Details Beware of stating assumptions about the form
or format of an input or output E.g. an output might be assumed to be on paper,
but why not a web page or PDF file? Be clear what assumptions are made about the
environment the user will have Don’t necessarily have a keyboard and mouse
INFO 627 Lecture #6 19
Requirements vs. Design Requirements (what the system does) should
be determined before design Requirements are determined by the users and
customers, since they (generally) know their needs best
Design (how) is done by technical experts, because they know the options available
INFO 627 Lecture #6 20
Requirements vs. Design Yet trying to implement requirements may
lead to a design which alters the req’ts Hence in reality, design and requirements are
iterative, feeding off each other until an acceptable balance is achieved
Changes in technology can drastically affect requirements (client/server vs. web)
INFO 627 Lecture #6 21
Types of Requirements A basic breakdown of requirements
may include: Functional software requirements Non-functional software requirements Design constraints
Functional requirements focus on actions (user does x, system does y)
1E p. 237
See also lecture 2, INFO 620 for the FURPS+ model
INFO 627 Lecture #6 22
Non-Functional Requirements Non-functional requirements typically
include: Usability
Time needed for training Time to perform task Usability compared to other systems Availability of help Compliance with HCI standards (Windows, Mac)
INFO 627 Lecture #6 23
Non-Functional Requirements Reliability
Availability (%) Mean time between failures (MTBF, hours) Mean time to repair (MTTR, hours) Accuracy (numeric precision, number of decimals) Defect rate (defects/1000 lines of code) Bugs per type (number of bugs by severity)
INFO 627 Lecture #6 24
Non-Functional Requirements Performance
Response time for a transaction – average, maximum, some % below some value
Throughput (transactions per second) Capacity (number of simultaneous users) Degraded modes of operation (what are performance
expectations if system is partially offline)
INFO 627 Lecture #6 25
Non-Functional Requirements Supportability
Expected implementation time for minor, medium, and major enhancements
Planned or possible future enhancements mostly affect design decisions
INFO 627 Lecture #6 26
Design Constraints We generally want to define requirements so
that several design approaches might be used to implement them
Constraints might need to be imposed such as the development language, use of corporate reuse libraries, coding standards, or external standards such as FDA, DOD or FCC regulations
INFO 627 Lecture #6 27
Design Constraints Should distinguish constraints from
requirements, such as using a “DC” prefix, and isolate them from the true requirements
Identify the source of each constraint, and why it was imposed (if known)
INFO 627 Lecture #6 28
Parent-Child Requirements A child requirement specifies details about
its parent Could look on as the parent is a requirement,
and the child a specification Don’t go crazy with lots of grandchildren and
great-grandchildren – usually not worth the effort
INFO 627 Lecture #6 29
Use Case Refinement Use cases make sense particularly when a
system has lots of functions to perform, and you’re using an OO methodology
If there are few users or interfaces, or extensive non-functional requirements, might not be the best choice
INFO 627 Lecture #6 30
Use Case Refinement Use cases focus on who does something
(actor), how they interact with the system, and what the system does in response (including tasks like saving data, displaying a report, etc.)
Use case must be of value to the actor Name each use case clearly and concisely
INFO 627 Lecture #6 31
Use Case Refinement Refinement of use cases may include:
The basic flow, or main success scenario Variants or alternative flows – such as different
methods of payment, processing personal versus business orders, or error conditions
Preconditions – what happens before this use case may be used?
Postconditions – what has changed as a result of this use case?
INFO 627 Lecture #6 32
Software Requirements Specification (SRS) A Software Requirements Specification
(SRS) defines the conceptual model of what the system will be
Main standard is IEEE 830:1998 SRS isn’t always a single document, but
a collection of documents and models Is a living package; evolves with the system
INFO 627 Lecture #6 33
SRS Purpose The SRS serves to communicate among the
developers and various stakeholders Represents an agreed contract as to what will
and won’t be in the system Provides a basis for tracking completion of
the system Feeds design, testing, training, etc.
INFO 627 Lecture #6 34
SRS Ownership The SRS is owned by the developers Often each part may have a separate owner
who is responsible for that part All are overseen by the Vision champion,
chief architect, and the program manager
INFO 627 Lecture #6 35
SRS Format There are many ways to arrange the contents
of an SRS Text provides one structure (1E pp. 266-267),
which assumes you are using use cases IEEE 830 provides another (p. 11 therein), which
is more generalized Not all sections apply to every system; use
“Not Applicable” if that’s the case
INFO 627 Lecture #6 36
SRS Contents Some parts of the SRS look like Vision
contents – purpose, scope, constraints, interfaces, documentation and help – but here the latter are described in more detail
Other issues are now addressed – licensing and legal issues, purchased components (implying some design concept), and all requirements are identified (not just key)
INFO 627 Lecture #6 37
SRS Contents The main body of the SRS is a detailed
description of the functional and non-functional requirements
Functional requirements can be broken down many ways
INFO 627 Lecture #6 38
Functional Requirements Functional requirements may be organized
(IEEE 830, App. A) by: Mode of operation of the system; best used for
software-intensive mechanical systems, each mode’s functional requirements are detailed (scanning mode, editing mode, acquisition mode, etc.) If needed, each mode’s interfaces, functional, and
performance requirements can be addressed
INFO 627 Lecture #6 39
Functional Requirements User class; where each type of user of the system
has well defined activities they must perform, then their functional requirements are listed
Class; for object oriented systems; each class is described in terms of its attributes, methods, and messages
INFO 627 Lecture #6 40
Functional Requirements Feature; similar to use case descriptions, identify
when and how each feature is to be used, and the functional requirements for each feature
Stimulus; useful when the system’s responses (functional requirements) are based on what kind of specific stimulus or message it receives
INFO 627 Lecture #6 41
Functional Requirements Functional hierarchy; break the requirements
down by information flow, process, or data construct, and provide a data dictionary to specify each data element’s format; good for reengineering legacy information systems
Or any combination of the above methods (multiple organizations), such as mixing user class then stimulus and response
INFO 627 Lecture #6 42
Non-Functional Requirements Non-functional requirements can be
documented according to the structure already outlined Usability Reliability Performance Supportability
INFO 627 Lecture #6 43
Balancing Requirements We need to review requirements for
Consistent level of detail throughout the system Adequate level of detail to guide implementation,
without over constraining that implementation Most of the SRS is text; graphics can be
helpful but beware of adding implied design