IEEE Std' 1233 IEEE Guide for Developing System Requirements Specifications

1
IEEE Std. 1233IEEE Guide for Developing System
Requirements Specifications

• Thomas G. CleaverUniversity of
  LouisvilleDepartment of Electrical and Computer
  EngineeringAug. 29, 2007

2
References

• This presentation was developed from
• IEEE Std. 1233, 1998 Edition, IEEE Guide for
  Developing System Requirements Specifications,
  Adobe Acrobat pdf file (1998, Dec. 8) Available
  at HTTP http//ieeexplore.ieee.org/iel4/5982/1601
  6/00741940.pdf?isNumber16016prodSTDarnumber74
  1940arStaredarAuthor
• Volere Requirements Specification Template,
  webpage (2005, Jan. 24) Available at HTTP
  http//www.systemguild.com/GuildSite/Robs/Template
  .html

3
Whats a Standard?

• A generic, all-encompassing term used to describe
  documents that provide a specified set of
  mandatory or discretionary rules, requirements,
  or conditions concerned with performance, design,
  operation, or measurements of quality to
  accomplish a specific task. Standards may include
  federal laws, regulations, state laws, federal
  agency directives, national and internal
  technical standards, codes of conduct, or
  organizational "internal use only" documents.
• (from the ES and H Manual, found at
  http//www.llnl.gov/es_and_h/hsm/doc_5.01/doc5-01.
  html, last accessed 1/25/05)

4
Who Issues Standards?

• US Government
• For example, USDA standards for grading meat.
• American National Standards Institute (ANSI)
• For example, National Electrical Safety Code.
• National Television Systems Committee
• For example, NTSC standard (525-line, interlaced,
  raster-scanned video).
• World Wide Web Consortium (W3C)
• For example, Extensible Markup Language (XML)
  specifications.
• International Standards Organization (ISO)
• For example, MP3 (ISO-MPEG-1 Audio Layer-3).
• IEEE
• For example, IEEE Std. 1233, 1998 Edition, IEEE
  Guide for Developing System Requirements
  Specifications.
• And many other organizations.

5
Why Do We Need Standards?

• So equipment will work correctly.
• So equipment will work reliably.
• So various kinds of equipment can interconnect.
• To avoid Tower of Babel phenomena.

6
System Requirements Specification (SyRS)

• A document that communicates the requirements of
  the customer (customer can also include funding
  agency, overseers, and managers) to the technical
  community.
• Is understandable by both the customer and the
  technical community.
• Presents the results of the definition of need,
  the operational concept, and the system analysis
  tasks.
• Describes what the system must do, not how to
  construct the system.

7
Requirements Properties

• Unique Each requirement should be stated only
  once.
• Normalized Requirements should not overlap.
• Complete Requirements must include all of
  customers needs plus all those needed for the
  definition of the system.
• Consistent Requirements must not contradict
  others, including in style and level of detail.
• Modifiable Procedures are available to change
  the SyRS.
• Bounded Requirements are limited in scope.
• Granular All requirements are at the same level
  of detail.

8
SyRS Purpose

• Provide a black-box description of what the
  system should do.
• Describe all inputs, outputs, and the
  relationships among them.

9
Uses of the SyRS

• Used to define the requirements to all
  stakeholders.
• Used as a basis for concurrent design.
• Used as a basis for documenting (inevitable)
  design changes.
• Used in constructing the system.
• Used in developing the test plan.
• Used to verify to the customer that the delivered
  system is complete and correct.

10
(No Transcript)
11
Requirement Specification Components(Entries in
bold will be used in ECE 599.)

• Requirement ID
• Related Objective
• Requirement Type
• Description
• Rationale
• Capability
• Conditions
• Constraints
• Sources
• Fit Criterion
• Priority
• Criticality
• Feasibility
• Risk
• Dependencies
• Conflicts
• Supporting Materials
• History

12
Requirement ID

• A unique identifying name or number
• Examples
• Tuning Performance
• 3.5.7

13
Related Objective

• Relevant objective as stated in Needs Assessment
• Ideally one-to-one relationship (one objective
  for each requirement statement)
• But one-to-many and many-to-one may be necessary.
• None may be used if the requirement was not
  considered in the Needs Assessment.

14
Requirement Type Part 1(This component will
not be used in ECE 599.)

• The category of the requirement.
• Examples
• Input
• Output
• Reliability
• Availability
• Maintainability
• Performance
• Accessibility
• Environmental conditions
• Ergonomic
• Safety

15
Requirement Type Part 2

• Further Examples
• Security
• Facility Requirements
• Transportability
• Training
• Documentation
• External interfaces
• Testing
• Quality provisions
• Policy and regulatory
• Compatibility to existing systems

16
Requirement Type Part 3

• Further examples
• Standards and technical policies
• Conversion
• Growth capacity
• Installation
• Scalability
• Ease of use
• Ease of learning
• Open issue (unresolved)
• Off-the-shelf solution
• Schedule

17
Description

• A one-sentence description of the requirement.
• Should be very similar to the Related Objective.
• Should be numerical.
• Example
• The guitarist must be able to use the tuning
  device to tune all strings of a guitar within 1
  of the correct pitch within 5 minutes.

18
Rationale

• A short statement giving the reason for the
  requirement.
• Examples
• Accurate tuning of guitars is the main objective
  of this device.
• The device needs electrical power to function.

19
Capability(This component will not be used in
ECE 599.)

• What the system must do to meet the requirement.
• Examples
• The guitar tuner shall provide the user with
  feedback sufficient to tune a guitar accurately.
• The Users Manual will describe how the device is
  to be used and give hints for successful guitar
  tuning.

20
Conditions(This component will not be used in
ECE 599.)

• Quantitative or qualitative measures that
  describe the environment in which the device will
  be used.
• Examples
• The device is intended for indoor operation at
  room temperature.
• The typical user will be a learning guitarist.

21
Constraints(This component will not be used in
ECE 599.)

• Limitations, ranges, or tolerances on the way the
  problem must be solved.
• Examples
• The user must be able to use the device to tune
  each string within ?1 of the correct pitch.
• The visual indication of string pitch must be
  clearly visible from a distance of 1 m.
• The software must be based on Windows CE.

22
Sources(This component will not be used in ECE
599.)

• The name of the person or persons who originated
  the requirement.
• Examples
• Hiram Cheep, CEO of AGMC
• Design team

23
Fit Criterion

• Objective measure for defining the meaning of a
  requirement, and eventually testing whether a
  given solution satisfies the requirement.
• Examples
• The prototype will be tested at room temperature
  and must function correctly for a minimum of two
  hours.
• A guitarist sitting at a distance of 1 m from the
  device will be able to see the display well
  enough to tune a guitar.

24
Priority(This component will not be used in ECE
599.)

• The relative importance of the requirement when
  compared with other requirements, ranked on a
  scale from 1 to 10.
• Examples
• 3
• 7

25
Criticality(This component will not be used in
ECE 599.)

• The importance of this requirement, on a scale of
  1 to 10.
• Examples
• 5
• 2

26
Feasibility(This component will not be used in
ECE 599.)

• A measure of the probability (on a scale of 1 to
  10) that the requirement can actually be met.
  This may depend on technical feasibility, time
  constraints, and budget constraints.
• Examples
• 3
• 10

27
Risk(This component will not be used in ECE 599.)

• The risk of project failure if the requirement is
  not implemented, on a scale of 1 to 10. Low
  numbers are good.
• Examples
• 1
• 3

28
Dependencies(This component will not be used in
ECE 599.)

• List of other requirements that have an effect on
  this one and other requirements that are affected
  by this one.
• Examples
• System Stability
• Tuning Accuracy
• 6.2.5

29
Conflicts(This component will not be used in ECE
599.)

• List of other requirements that conflict with
  this one. This is a temporary situation. A
  completed SyRS should have no conflicts.
• Examples
• Tuning Accuracy
• Battery Life
• 17.4

30
Supporting Materials(This component will not be
used in ECE 599.)

• References (usually) to materials giving more
  detail about the requirement. Frequently,
  supporting materials are in an appendix to the
  SyRS.
• Examples
• Company policy on software maintenance. See
  Appendix A.
• Please see OSHA 29 CFR 910

31
History(This component will not be used in ECE
599.)

• Date the document was created and dates of each
  change to this requirement.
• You will not be required to go through the update
  process to modify a completed SyRS instead you
  will document any changes in your final report.
• Examples
• Created January 19, 2005.
• Created March 1, 2004 modified March 25, 2004.