CIS 890: Safety Critical Systems

Transcription

1 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.

2 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

3 Software Development Ecosphere Goals Design Agreement, Shared View? Assumptions Domain Knowledge

4 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.

5 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".

6 Stakeholders Nowhere more than in the requirements process do the interests of all the stakeholders in a software or system project intersect 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.

7 Stakeholders Nowhere more than in the requirements process do the interests of all the stakeholders in a software or system project intersect 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. 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.

8 Importance of Requirements The importance of requirements is often overlooked in the small, relatively clearly defined programming projects that you encounter as a student. 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.

9 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.

10 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)

11 Definition Many definitions of requirement have been proposed in the context of computer science. Requirements are... "anything that drives design choices. -- Lawrence (1997)

12 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!)

13 Definition Many definitions of requirement have been proposed in the context of computer science. 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

14 Kinds of Requirements There are several different flavors 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 NOTE: We usually don t list this information explicitly in requirements for safety-critical systems, but might provide it in a background section.

15 Kinds of Requirements There are several different flavors 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.

16 Kinds of Requirements There are several different flavors 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.

17 Kinds of Requirements There are several different flavors 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. 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.

18 Kinds of Requirements There are several different flavors 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 a reservation

19 Kinds of Requirements There are several different flavors 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.

20 Kinds of Requirements There are several different flavors 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)

21 Kinds of Requirements There are several different flavors 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

22 Kinds of Requirements There are several different flavors of requirements External Interfaces describe external interfaces between the system and the outside world E.g., use of a database package or web-service

23 Kinds of Requirements Relating different kinds of requirements Wiegers, Karl (2009). Software Requirements (Chapter 1)

24 SRS The Software Requirements Specification document 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.

25 SRS Several audiences rely on the 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.

26 SRS Outline A possible outline for an SRS is given below

27 Requirements Statement Characteristics of good requirements statements 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.

28 Requirements Statement Characteristics of good requirements statements 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.

29 Requirements Statement Characteristics of good requirements statements 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.

30 Requirements Statement Characteristics of good requirements statements 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.

31 Requirements Statement Characteristics of good requirements statements 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.

32 Requirements Statement Characteristics of good requirements statements 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.

33 Requirements Statement Characteristics of good requirements statements 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).

34 Requirements Specifications 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.

35 Requirements Specifications Characteristics of good 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.

36 Requirements Specifications Characteristics of good 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.

37 Requirements Specifications Characteristics of good 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.

38 Requirements Specifications Characteristics of good 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.

39 Summary Requirements development/management is a crucial part of any significant software development project 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.

40 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.

41 Acknowledgements The material in this lecture is based almost entirely on Software Requirements (2 nd Ed.), Karl E. Wiegers, Microsoft Press, 2003.