IEEE 1233 1996:1998 Edition

$76.38

IEEE Guide for Developing System Requirements Specifications

Published By	Publication Date	Number of Pages
IEEE	1998	29

Guaranteed Safe Checkout

Category: IEEE

If you have any questions, feel free to reach out to our online customer service team by clicking on the bottom right corner. We’re here to assist you 24/7.
Email:[email protected]

Description

New IEEE Standard – Inactive – Superseded. This IEEE Standards product is part of the family on Software Engineering. Guidance for the development of the set of requirements, System Requirements Specification (SyRS), that will satisfy an expressed need is provided. Developing a SyRS includes the identification, organization, presentation, and modification of the requirements. Also addressed are the conditions for incorporating operational concepts, design constaints, and design confiquration requirements into the specification. This guide also covers the necessary characteristics and qualities of individual requirements and the set of all requirements.

PDF Catalog

PDF Pages	PDF Title
1	IEEE Guide for Developing System Requirements Specifications
5	CONTENTS
6	IEEE Guide for Developing System Requirements Specifications 1. Overview 1.1 Scope 2. References
7	3. Definitions 3.1 analyst: A member of the technical community (such as a systems engineer or business analyst,… 3.2 annotation: Further documentation accompanying a requirement such as background information a… 3.3 baseline: A specification or system that has been formally reviewed and agreed upon, that the… 3.4 constraint: A statement that expresses measurable bounds for element or function of the syste… 3.5 customer(s): The entity or entities for whom the requirements are to be satisfied in the syst… 3.6 derived requirement: A requirement deduced or inferred from the collection and organization o… 3.7 element: A component of a system; may include equipment, a computer program, or a human.
8	3.8 end user: The person or persons who will ultimately be using the system for its intended purp… 3.9 environment: The circumstances, objects, and conditions that will influence the completed sys… 3.10 function: A task, action, or activity that must be accomplished to achieve a desired outcome. 3.11 model: A representation of a real world process, device, or concept. 3.12 prototype: An experimental model, either functional or non functional, of the system or part… 3.13 raw requirement: An environmental or customer requirement that has not been analyzed and for… 3.14 representation: A likeness, picture, drawing, block diagram, description, or symbol that log… 3.15 requirement: (a) A condition or capability needed by a user to solve a problem or achieve an… 3.16 system: An interdependent group of people, objects, and procedures constituted to achieve de… 3.17 System Requirements Specification (SyRS): The System Requirements Specification consists of … 3.18 testability: The degree to which a requirement is stated in terms that permit establishment … 3.19 traceability: The degree to which a relationship can be established between two or more prod… 3.20 validation: The process of evaluating a system or component during or at the end of the deve… 3.21 verification: The process of evaluating a system or component to determine whether the syste… 3.22 well-formed requirement: A statement of system functionality (a capability) that can be vali…
9	4. System requirements specification 4.1 Definition 4.2 Properties a) Unique Set: Each requirement should be stated only once. b) Normalized: Requirements should not overlap, that is, they shall not refer to other requiremen… c) Linked Set: Explicit relationships should be defined among individual requirements to show how… d) Complete: An SyRS should include all the requirements identified by the customer, as well as t… e) Consistent: SyRS content should be consistent and non contradictory in the level of detail, st… f) Bounded: The boundaries, scope, and context for the set of requirements should be identified. g) Modifiable: The SyRS should be modifiable. Clarity and non overlapping requirements contribute… h) Configurable: Versions should be maintained versions time and across instances of the SyRS. i) Granular: This should be the level of abstraction for the system being defined.
10	4.3 Purpose 4.3.1 Organizing requirements a) Identify requirements that are derived from other requirements b) Organize requirements of different levels of detail into their appropriate levels c) Verify the completeness of the set of requirements d) Identify inconsistencies among requirements e) Clearly identify the capabilities, conditions, and constraints for each requirement f) Develop a common understanding with the customer of the purpose and objectives of the set of r… g) Identify requirements that will complete the SyRS 4.3.2 Communicating to two audiences
11	4.3.2.1 Customer 4.3.2.2 Technical community 4.4 Intended use a) During Systems Design, requirements are allocated to subsystems, hardware, software, operation… b) The SyRS is utilized in constructing the resulting system. The SyRS is also used to write appr… c) During the Implementation phase, test procedures will be defined from the SyRS. d) During the validation process, validation procedures based on the SyRS are used to provide the… 4.5 Benefits a) Assurance to the customer that the technical community understands customer’s needs and is res… b) An early opportunity for bi-directional feedback between the customer and the technical commun… c) A method for the customer and the technical community to identify problems and misunderstandin… d) A basis for system qualification to establish that the system meets the customers’ needs e) Protection for the technical community, providing a baseline for system capabilities and a bas… f) Support for the developer’s program planning, design, and development efforts g) Aids in assessing the effects of the inevitable requirement changes h) Increased protection against customer and technical community misunderstandings as development…
12	4.6 Dynamics of system requirements 5. SyRS development process overview Figure 1— Context for developing an SyRS 5.1 Customer 5.1.1 Raw requirements
13	a) Concept of operations: This type of document focuses on the goals, objectives and general desi… b) System concept: This type of document includes concept of operations information, but will als… c) Marketing specification: This type of document includes a features list (often in bullet forma… d) Request for proposal: In some instances a Request for Proposal will be prepared. This may incl… e) External system interfaces: The definition of all interfaces external to the system, literally… 5.1.2 Customer representation 5.1.3 Customer feedback 5.2 Environment
14	a) Political b) Market c) Standards and technical policies d) Cultural e) Organizational f) Physical 5.2.1 Political influence 5.2.2 Market influence a) Functionality b) Price c) Reliability d) Durability e) Performance f) Maintainability g) System safety & security
15	5.2.3 Standards and technical policies influence a) System consistency b) System safety c) System reliability and maintainability 5.2.4 Cultural influence 5.2.5 Organizational influence 5.2.6 Physical influence 5.3 Technical community
16	5.3.1 Technical representation 5.3.2 Technical feedback 6. Well-formed requirements 6.1 Definition of well-formed requirement 6.1.1 Capabilities
17	6.1.2 Conditions 6.1.3 Constraints 6.1.4 Example
18	6.2 Properties of a requirement a) Abstract: Each requirement should be implementation independent b) Unambiguous: Each requirement should be stated in such a way so that it can be interpreted in … c) Traceable: For each requirement it should be feasible to determine a relationship between spec… d) Validatable: Each requirement should have the means to prove that the system satisfies the req… 6.3 Categorization a) Identification: Each requirement should be uniquely identified (i.e., number, name tag, mnemon… b) Priority: The customer should identify the priority of each requirement. This may be establish… c) Criticality: The analyst, working with the customer, should define the criticality of each req… d) Feasibility: The customer and analyst working together should identify the feasibility of incl… e) Risk: Risk analysis techniques can be used to determine a grading for system requirements. In … f) Source: Each requirement should be further classified by a label that indicates the originator… g) Type: Requirements can also be categorized by one or more of the following types:
19	6.4 Pitfalls a) Design & Implementation: There is a tendency on the part of analysts and customers who are def… b) Overspecification: c) Overconstrained: Requirements with unnecessary constraints (For example, if a system must be a… d) Unbounded: e) Assumptions:
20	7. SyRS development a) Identify requirements from the customer, the environment, and the experience of the technical … b) Build well-formed requirements c) Organize the requirements into an SyRS d) Present the SyRS in various representations for different audiences Figure 2— SyRS development process 7.1 Identify requirements
21	a) The process is goal-directed and aimed at the production of a set of requirements b) The system boundaries are defined c) All requirements are solicited, fairly evaluated, and documented d) Requirements are specified as capabilities and that qualifying conditions and bounding constra… e) Requirements are validated, or purged if invalid, from the requirements set f) Consideration is given to consistency when many individuals (“authors”) may be contributing to… g) The developing requirements set is understood, at an appropriate level of detail, by all indiv… 7.1.1 Techniques for identifying requirements a) Structured workshops b) Brainstorming or problem-solving sessions c) Interviews d) Surveys/questionnaires e) Observation of work patterns (e.g., time and motion studies) f) Observation of the system’s organizational and political environment (e.g., sociogram) g) Technical documentation review h) Market analysis i) Competitive system assessment j) Reverse engineering k) Simulations l) Prototyping m) Benchmarking processes and systems
22	7.1.2 Interaction between customers and analysts 7.1.2.1 Mutual education 7.1.2.2 Joint definition of requirements 7.2 Build a well-formed requirement a) Ensuring that each requirement is a necessary, short, definitive statement of need (capability… b) Defining the appropriate conditions (quantitative or qualitative measures) for each requiremen… c) Avoiding requirements pitfalls (see 6.4) d) Ensuring the readability of requirements, which entails the following:
23	e) Ensuring testability 7.3 Organize requirements a) Searching for patterns around which to group requirements b) Utilizing experience and judgment to account for appropriate technical approaches c) Utilizing creativity and intuition to generate alternative approaches and to prioritize requir… d) Defining the requirements properties e) Defining the requirement attributes
24	a) Events b) Information/data c) Physical or abstract objects d) Functions 7.4 Present requirements a) The customer and technical community usually have different cultures and languages, thus, the … b) Retrieval of specific information is difficult in some representations c) Representation of interactions can be difficult to do in some representations d) Relating information in one place to information in another place can be difficult in some rep… 7.4.1 Methods of representation a) Textual b) Model
25	Annex A (informative) An SyRS outline
26	a) Identify the system to be produced by name. b) Refer to and state the results of the earlier finalized needs analysis, in the form of a brief… c) Describe the application of the system being specified. As a portion of this, it should descri…
27	a) Dynamic actions or changes that occur (e.g., rates, velocities, movements, and noise levels). b) Quantitative criteria covering endurance capabilities of the equipment required to meet the us… c) Performance requirements for the operational phases and modes. a) Time (e.g., mean and maximum downtime, reaction time, turnaround time, mean and maximum times … b) Rate (e.g., maintenance staff hours per specific maintenance action, operational ready rate, m… c) Maintenance complexity (e.g., number of people and skill levels, variety of support equipment) d) Maintenance action indices (e.g., maintenance costs per operating hour, staff hours per overhaul)
29	Annex B (informative) Bibliography [B1] Blanchard, Benjamin S. System Engineering Management. Wiley-Interscience, 1991. [B2] Blanchard, Benjamin S., and Walter J. Fabrycsky. Systems Engineering & Analysis. Internation… [B3] Gause, Donald C., and Gerald M. Weinberg. Exploring Requirements: Quality Before Design. Dor…