cis 890: safety critical systems - santoslab.org · the software requirements specification...
TRANSCRIPT
CIS 890 -- Requirements -- Introduction
CIS 890: Safety Critical Systems
Lecture: Requirements – Introduction
Copyright 2011, John Hatcliff. The syllabus and all lectures for this course are copyrighted materials and may not be used in other course settings outside of Kansas State University in their current form or modified form without the express written permission of one of the copyright holders. During this course, students are prohibited from selling notes to or being paid for taking notes by any person or commercial firm without the express written permission of one of the copyright holders.
CIS 890 -- Requirements -- Introduction
Objectives
Understand the role requirements play in a software development process
Identify the primary stakeholders in requirements management
Survey different types of requirements Understand the general structure of a
requirements document List characteristics of good requirements
Software Development Ecosphere
CIS 890 -- Requirements -- Introduction
Domain Knowledge
Goals Assumptions
Design
Agreement, Shared View
?
CIS 890 -- Requirements -- Introduction
Importance of Requirements
Errors made during the requirements stage account for 40 to 60 percent of all defects found in a software project
-- Davis 1993; Leffingwell 1997.
CIS 890 -- Requirements -- Introduction
Importance of Requirements
The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines, and to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify.
-- Fred Brooks, in "No Silver Bullet: Essence and Accidents of Software Engineering".
CIS 890 -- Requirements -- Introduction
Stakeholders
Customers -- fund a project or acquire a product to satisfy their organization’s business objectives.
Users -- interact directly or indirectly with the product (a subclass of customers).
Requirements analysts -- write the requirements and communicate them to the development community.
Developers -- design, implement, and maintain the product. Testers -- determine whether the product behaves as intended. Documentation writers -- produce user manuals, training materials,
and help systems.
Nowhere more than in the requirements process do the interests of all the stakeholders in a software or system project intersect
CIS 890 -- Requirements -- Introduction
Stakeholders
Manufacturing people – must build the products that contain software.
Sales, marketing, field support, help desk, etc. -- who will have to work with the product and its customers.
Nowhere more than in the requirements process do the interests of all the stakeholders in a software or system project intersect
Because requirements are the foundation for both the software development and the project management activities, all stakeholders must be committed to following an effective requirements process.
Importance of Requirements
You usually get the “requirements” (in the form of a homework description) in a fully formed state directly from the instructor.
There is no iterative process of establishing “agreement” because “what the instructor says, goes”.
There are only two stakeholders: you and the instructor. The projects are often small enough that there are very few non-trivial
complexities that need to be understood. For pedagogical reasons (e.g., “to relate to what students know”), the
application domain is often quite familiar to you. Due to time pressures (i.e., a course is 16 weeks), instructors don’t have
time to walk you through an iterative requirements development process.
CIS 890 -- Requirements -- Introduction
The importance of requirements is often overlooked in the small, relatively clearly defined programming projects that you encounter as a student.
CIS 890 -- Requirements -- Introduction
Definition Many definitions of “requirement” have been proposed in the context of computer science.
1. A condition or capability needed by a user to solve a problem or achieve an objective.
2. A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document.
3. A documented representation of a condition or capability as in 1 or 2
-- IEEE Standard Glossary of Software Engineering Terminology (1990)
NOTE: The term “user” should be generalized to “stakeholder” because not all stakeholders are users.
CIS 890 -- Requirements -- Introduction
Definition Many definitions of “requirement” have been proposed in the context of computer science.
Requirements are...a specification of what should be implemented. They are descriptions of how the system should behave, or of a system property or attribute. They may be a constraint on the development process of the system.
-- Sommerville and Sawyer (1997)
CIS 890 -- Requirements -- Introduction
Definition Many definitions of “requirement” have been proposed in the context of computer science.
Requirements are... "anything that drives design choices”.
-- Lawrence (1997)
CIS 890 -- Requirements -- Introduction
Definition Many definitions of “requirement” have been proposed in the context of computer science.
A statement of a customer need or objective, or of a condition or capability that a product must possess to satisfy such a need or objective. A property that a product must have to provide value to a stakeholder.
-- Wiegers, Karl (2009). Software Requirements
NOTE: We will use this definition (for now!)
Definition
Clearly, there’s no universal definition of what a requirement is
To facilitate communication, we need to agree on a consistent set of adjectives to modify the overloaded term requirement
We need to appreciate the value of recording these requirements in a shareable form
CIS 890 -- Requirements -- Introduction
Many definitions of “requirement” have been proposed in the context of computer science.
Kinds of Requirements
Business requirements Represent high-level objectives of the organization or customer
who requests the system. Typically come from the funding sponsor for a project, the
acquiring customer, the manager of the actual users, the marketing department, or a product visionary.
Describe why the organization is implementing the system—the objectives the organization hopes to achieve.
Typically recorded the business requirements in a vision and scope document
CIS 890 -- Requirements -- Introduction
There are several different “flavors” of requirements
NOTE: We usually don’t list this information explicitly in requirements for safety-critical systems, but might provide it in a background section.
Kinds of Requirements
Business requirements -- examples Achieve a customer satisfaction measure of at least X within Y
months of release. Increase transaction-processing productivity by X% and reduce
data error rate to no more than Y%. Reach a sales volume of X units or revenue of $Y within Z
months.
CIS 890 -- Requirements -- Introduction
There are several different “flavors” of requirements
Kinds of Requirements
User Requirements Describe user goals or tasks that the users must be able to
perform with the product. May be represented by use cases, scenario descriptions, and
event-response tables. Describe what the user will be able to do with the system.
CIS 890 -- Requirements -- Introduction
There are several different “flavors” of requirements
Kinds of Requirements
User Requirements -- examples ”Enable the user to print a mailing label for a package." ”Enable the user to manage a queue of chemical samples
waiting to be analyzed." ”Enable the user to calibrate the pump controller.”
CIS 890 -- Requirements -- Introduction
There are several different “flavors” of requirements
NOTE: This sort of information would typically become the title/subject of use-cases in the FAA REMH, and the capabilities above would be broken down into a series of user interactions with the system.
Kinds of Requirements
Functional Requirements Specify the software functionality that the developers must build
into the product to enable users to accomplish their tasks, thereby satisfying the business requirements.
Sometimes called behavioral requirements, these are the traditional "shall" statements: "The system shall e-mail a reservation”
CIS 890 -- Requirements -- Introduction
There are several different “flavors” of requirements
Kinds of Requirements
Functional Requirements -- examples The user shall be able to toggle between displaying and hiding
all XML tags in the document being edited with the activation of a specific triggering mechanism. The display shall change in 0.1 second or less.
At the time the requester enters a charge number, the system shall validate the charge number against the master corporate charge number list. If the charge number is not found on the list, the system shall display an error message and shall not accept the order.
CIS 890 -- Requirements -- Introduction
There are several different “flavors” of requirements
Kinds of Requirements
Business rules Business rules include corporate policies, government
regulations, industry standards, accounting practices, and computational algorithms.
Business rules are not themselves software requirements because they exist outside the boundaries of any specific software system. However, they often restrict who can perform certain use cases or they dictate that the system must contain functionality to comply with the pertinent rules.
Sometimes business rules are the origin of specific quality attributes that are implemented in system functionality (you may trace specific functional requirements back to business rules)
CIS 890 -- Requirements -- Introduction
There are several different “flavors” of requirements
Kinds of Requirements
Quality Attribute Augment the description of the product’s functionality by
describing the product’s characteristics in various dimensions that are important either to users or to developers.
E.g., usability, portability, integrity, efficiency, and robustness. – There are many forms of non-functional requirements
Specific example – Performance Requirement (non-functional) The system SHALL handle 1,000 transactions per second
CIS 890 -- Requirements -- Introduction
There are several different “flavors” of requirements
Kinds of Requirements
External Interfaces describe external interfaces between the system and the
outside world E.g., use of a database package or web-service
CIS 890 -- Requirements -- Introduction
There are several different “flavors” of requirements
Kinds of Requirements
CIS 890 -- Requirements -- Introduction
Relating different kinds of requirements
Wiegers, Karl (2009). “Software Requirements” (Chapter 1)
SRS
Functional requirements are documented in a software requirements specification (SRS), which describes as fully as necessary the expected behavior of the software system.
The SRS is used in development, testing, quality assurance, project management, and related project functions.
CIS 890 -- Requirements -- Introduction
The Software Requirements Specification document
SRS
Customers, the marketing department, and sales staff need to know what product they can expect to be delivered.
Project managers base their estimates of schedule, effort, and resources on the product description.
Software development team relies on SRS to know what to build. The testing group uses the SRS to develop test plans, cases, and
procedures. The SRS tells maintenance and support staff what each part of the product
is supposed to do. Documentation writers base user manuals and help screens on the SRS
and the user interface design. Training personnel use the SRS and user documentation to develop
educational materials. Legal staff ensure that the requirements comply with applicable laws and
regulations. Subcontractors base their work on, and can be legally held to, the SRS.
CIS 890 -- Requirements -- Introduction
Several audiences rely on the SRS
SRS Outline
CIS 890 -- Requirements -- Introduction
A possible outline for an SRS is given below
Requirements Statement
Complete Each requirement must fully describe the functionality to be delivered. It must contain all the information necessary for the developer to design and
implement that bit of functionality. If you know you’re lacking certain information, use TBD (to be determined) as a
standard flag to highlight these gaps. Resolve all TBDs in each portion of the requirements before you proceed with
construction of that portion.
CIS 890 -- Requirements -- Introduction
Characteristics of good requirements statements
Requirements Statement
Correct Each requirement must accurately describe the functionality to be built. The reference for correctness is the source of the requirement, such as
an actual user or a high-level system requirement. A software requirement that conflicts with its parent system
requirement is not correct. Only user representatives can determine the correctness of user
requirements, which is why users or their close surrogates must review the requirements.
CIS 890 -- Requirements -- Introduction
Characteristics of good requirements statements
Requirements Statement
Feasible It must be possible to implement each requirement within the
known capabilities and limitations of the system and its operating environment.
To avoid specifying unattainable requirements, have a developer work with marketing or the requirements analyst throughout the elicitation process.
CIS 890 -- Requirements -- Introduction
Characteristics of good requirements statements
Requirements Statement
Necessary Each requirement should document a capability that the
customers really need or one that’s required for conformance to an external system requirement or a standard.
Every requirement should originate from a source that has the authority to specify requirements.
Trace each requirement back to specific voice-of-the-customer input, such as a use case, a business rule, or some other origin.
CIS 890 -- Requirements -- Introduction
Characteristics of good requirements statements
Requirements Statement
Prioritized Assign an implementation priority to each functional
requirement, feature, or use case to indicate how essential it is to a particular product release.
If all the requirements are considered equally important, it’s hard for the project manager to respond to budget cuts, schedule overruns, personnel losses, or new requirements added during development.
CIS 890 -- Requirements -- Introduction
Characteristics of good requirements statements
Requirements Statement
Unambiguous All readers of a requirement statement should arrive at a single,
consistent interpretation of it, but natural language is highly prone to ambiguity.
Write requirements in simple, concise, straightforward language appropriate to the user domain.
"Comprehensible" is a requirement quality goal related to "unambiguous": readers must be able to understand what each requirement is saying.
Define all specialized terms and terms that might confuse readers in a glossary.
CIS 890 -- Requirements -- Introduction
Characteristics of good requirements statements
Requirements Statement
Verifiable See whether you can devise a few tests or use other verification
approaches, such as inspection or demonstration, to determine whether the product properly implements each requirement.
If a requirement isn’t verifiable, determining whether it was correctly implemented becomes a matter of opinion, not objective analysis.
Requirements that are incomplete, inconsistent, infeasible, or ambiguous are also unverifiable (Drabick 1999).
CIS 890 -- Requirements -- Introduction
Characteristics of good requirements statements
Requirements Specifications
CIS 890 -- Requirements -- Introduction
It’s not enough to have excellent individual requirement statements. Sets of requirements that are collected into a specification ought to exhibit the characteristics described in the following slides.
Requirements Specifications
Complete No requirements or necessary information should be missing. Missing requirements are hard to spot because they aren’t
there! Various techniques are available to help find missing
requirements – Focusing on user tasks, rather than system functions, can help you to prevent incompleteness.
CIS 890 -- Requirements -- Introduction
Characteristics of good requirements specifications
Requirements Specifications
Consistent Consistent requirements don’t conflict with other requirements
of the same type or with higher-level business, system, or user requirements.
Disagreements between requirements must be resolved before development can proceed.
You might not know which single requirement (if any) is correct until you do some research.
Recording the originator of each requirement lets you know who to talk to if you discover conflicts.
CIS 890 -- Requirements -- Introduction
Characteristics of good requirements specifications
Requirements Specifications
Modifiable You must be able to revise the SRS when necessary and to maintain a
history of changes made to each requirement. This dictates that each requirement be uniquely labeled and expressed
separately from other requirements so that you can refer to it unambiguously.
Each requirement should appear only once in the SRS. It’s easy to generate inconsistencies by changing only one instance of a duplicated requirement. Consider cross-referencing subsequent instances back to the original statement instead of duplicating the requirement.
A table of contents and an index will make the SRS easier to modify. Storing requirements in a database or a commercial requirements
management tool makes them into reusable objects.
CIS 890 -- Requirements -- Introduction
Characteristics of good requirements specifications
Requirements Specifications
Traceable A traceable requirement can be linked backward to its origin
and forward to the design elements and source code that implement it and to the test cases that verify the implementation as correct.
Traceable requirements are uniquely labeled with persistent identifiers. They are written in a structured, fine-grained way as opposed to crafting long narrative paragraphs.
Avoid lumping multiple requirements together into a single statement; the different requirements might trace to different design and code elements.
CIS 890 -- Requirements -- Introduction
Characteristics of good requirements specifications
CIS 890 -- Requirements -- Introduction
Summary
Requirements establish agreement among all stakeholders concerning the functionality/properties that the resulting system must provide.
Mistakes in requirements can often have a significant negative impact on the rest of development.
There are multiple flavors of requirements; the two primary categories are functional and non-functional requirements.
It’s important to understand the characteristics of a good set of requirements.
Requirements development/management is a crucial part of any significant software development project
CIS 890 -- Requirements -- Introduction
For You To Do
List the primary stakeholders (identified in this lecture) in requirements management.
Provide a good definition of requirements that addresses both functional and non-functional aspects.
List characteristics of good requirements statements. List characteristics of good requirements specifications. Discuss the concept of requirements traceability and its
importance in development.
CIS 890 -- Requirements -- Introduction
Acknowledgements
The material in this lecture is based almost entirely on Software Requirements (2nd Ed.), Karl E. Wiegers, Microsoft
Press, 2003.