cnotes3 - Requirements Specification: A structured document...

Info iconThis preview shows pages 1–6. Sign up to view the full content.

View Full Document Right Arrow Icon

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: Requirements Specification: A structured document that sets out the services the system is expected to provide. Should be precise so that it can act as a contract between the system procurer and software developer. Needs to be understandable by both. Describes what the system will do but not how it will do it (objectives but not how objectives will be achieved. Design Specification: An abstract description of the software that serves as a basis for (or describes) detailed design and implementation Describes how the requirements will be achieved. Primary readers will be software designers and implementers rather than users or management. Goals and constraints specified in requirements document should be traceable to the design specification (and from there to the code. Contents of Requirements Documents Introduction: Describes the need for the system and places it in context, briefly describing its functions and presenting a rationale for the software. Describes how the system fits into the overall business or strategic objectives of the organization commissioning the software. System Model: Shows the relationships between the system components and the system and its environment. An abstract data model should also be described if appropriate to the type of system. System Evolution: Fundamental assumptions on which the system is based and anticipated changes due to hardware evolution, changing user needs, etc. Functional Requirements: The services provided for the user. This includes timing and accuracy requirements. Contents of Requirements Documents (2) Constraints: Constraints on how the goals can be achieved (restrictions on behavior of software and freedom of designer), e.g., safety, hardware, programming languages, standards that must be followed. Includes quality requirements such as maintainability, availability, etc. Priorities: Guides tradeoffs and design decisions if all requirements and constraints cannot be completely achieved. Interfaces to the Environment: Input or output interfaces and relevant assumptions about environmental components with which the software will be interacting. Glossary: Definitions of technical terms used in the document. Indexes: Various types of indexes may be provided. Attributes of a good requirements document: Readable and understandable by customers, users, and designers. Specifies only external system behavior (black box) Structured to be easy to change. Specifies both goals and constraints. Able to serves as a reference for system maintainers. Consistent, complete, unambiguous, realistic, and testable Specified acceptable responses to undesired events. Specifies what should not do as well as what should do. Specified incremental subsets if desried or minimum and maximum functionality Specifies changes anticipated in the future (for both environment and software) Requirements must be testable An untestable requirement: The system shall be easy to use by experienced controllers and shall be organized in such a way...
View Full Document

This note was uploaded on 11/07/2011 for the course AERO 16.36 taught by Professor Alexandremegretski during the Spring '09 term at MIT.

Page1 / 37

cnotes3 - Requirements Specification: A structured document...

This preview shows document pages 1 - 6. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online