Unit 5 Study Guide and Review: Software Requirements Analysis
5a. Interpret fundamental software requirements and analysis terms
- What are key terms for the Requirements Analysis Phase of software development?
- What are the types of software requirements?
- How is the quality of software requirements described?
Key terms for requirements are underlined below. First, keep in mind that the purpose of software requirements analysis is to specify the problem to be solved or a task to be performed by the software. Second, keep in mind that software may be a subsystem of a larger system, and therefore the software requirements is a subproblem or subtask of the larger system. Third, software requirements analysis identifies what the software system will do, not how it will do it. To review, read the introduction to Unit 5.
Requirements are elicited using the data gathering techniques discussed in Unit 4. Requirements can be functional or nonfunctional. A functional requirement specifies what the software shall do and what it shall not do. What is a nonfunctional requirement? Performance, Interface, Design, and Development Standards are non-functional requirements (see page 25 of The New Software Engineering). Requirements are written as simple, concise, unambiguous, 'shall' statements. They can also be represented in a requirements model using diagrams together with text that express the types and properties of data. The requirements model is the starting model for the software development and will be transformed into models of other life-cycle phases. The requirements statements or model is analyzed to determine the attributes of the requirements. Attributes are used to determine the quality of the requirements, such as whether the requirements are complete, consistent, traceable, and so on. Complete means that all of the needs of the customer or client are addressed by the requirements; consistent means that there are no contradictions between requirements; traceable means that the connection between the requirements, design, and implementation elements are documented. What are some other attributes of requirements?
Software requirements must not contradict; this means that they must be consistent with other requirements, with the requirements of the larger system of which the software is a part, and with the products of the design and implementation phases. Moreover, requirements should be traceable to system (that is, any containing system) requirements and to elements of other life-cycle phases. For example, they should be traceable to software tests.
A requirements engineering role is responsible for the requirements. Requirements have many stakeholders, including customers, software designers, testers, etc. Name some other stakeholders. Requirements are used to validate the software system, its design, and its implementation. How are the requirements themselves validated? Testers test the software to determine if it satisfies the requirements. Project managers use the requirements model to organize, plan, and manage the project. A requirements change management role is responsible for identifying the requirements and for approving and controlling changes to requirements. To review, read How do You Write Software Requirements?.
5b. Practice the four activities of software requirements and analysis
- Describe the main activities of the Requirements Phase.
The Requirements Phase of a life-cycle development model corresponds to the problem definition stage of problem solving. A critical step in solving a problem is to acquire a thorough understanding of the problem by collecting relevant data, analyzing the data, concisely and clearly specifying the problem, and validating the problem specification. For software engineering and the requirements phase of a life cycle development, these steps are stated as 1) elicit requirements, 2) analyze the requirements, 3) specify the requirements, 4) verify and validate them. Each of these steps can be described by a process and performed using a method, such as object-oriented analysis. To review, read Highways of Requirements Engineering. This document lists 5 tasks of requirements engineering. Excluding requirements management, which is a process for controlling changes to the requirements, the remaining four summarize the activities of the requirements phase.
5c. Use the various requirements elicitation techniques
- How are requirements obtained?
Data collection techniques have strengths and weaknesses depending on the properties of the data to be collected, and the data properties depend on the type of the application. Review the tables on pages 99-101 of The New Software Engineering. Selecting several data collection techniques that have complementary strengths helps maximize effectiveness and efficiency of data collection.
What is special about the data for requirements that makes it different from that of other phases? First, since the requirements phase is typically the initial phase, it is the start of data collection. Other phases will have a body of data already collected and will add to it. Second, requirements elicitation will likely have the largest percentage of customer and user interaction and involvement. Third, requirements analysis addresses the definition of the problem or task and what computations the software will do. The other phases address the solution to the problem or task and how the software will perform the computation.
5d. Describe the conceptual foundation underlying data-oriented, process-oriented, and object-oriented methodologies
- What methods and/or methodologies are used to guide the Requirements Phase activities and produce software requirements?
- How do requirements methods help in the production of the requirements specification?
Requirements analysis and specification are performed using methods of three methodology categories: process-oriented, data-oriented, and object-oriented. Each of the methods provides guidance in building a process model, data model, or object model, respectively. These models express the elements needed to specify the requirements.
Process-oriented methods view a system as a hierarchy of processes related by decomposition. A system performs a process, has inputs, and produces outputs. A system is decomposed into component systems (subsystems), each having inputs and outputs, at the next level. Decomposition continues until elementary components, which cannot be decomposed, are reached.
Data-oriented methods view a system as a collection of data entities and entity relationships. Application relationships determine the processing of the entities and their domain values.
Object-oriented methods view a system as a hierarchy of objects related by inheritance. An object is an encapsulated unit of data and methods (functions). Objects interact by messages (for example, calls to the methods of an object).
In the requirements phase, these methods provide guidance in defining an initial process model, data model, or object model, respectively, of the problem domain. This initial model supports the specification of good requirements in terms of processes, data, or objects, depending on the methodology. In later, phases, the methods guide the transformation of the initial model to a solution model, for the respective method. To review, read this article on the characteristics of good software requirements.
5e. Describe the analysis activities and their major representations in data-oriented, process-oriented, and object-oriented methodologies
- What are the activities of requirements analysis?
- How are the work products of the Requirements Phase activities represented?
Consider object-oriented analysis. Object-oriented analysis activities are part of the requirements phase. It identifies those objects, processes, attributes, and classes. It assigns processes (called methods) to the objects, and defines the attributes (i.e. data for objects and properties for processes). These elements are typically represented using tables and text. What are some object-oriented artifacts used to document and communicate to stakeholders the objects and their elements? Relationships between objects and object classes, intra-object control, inter-object event processing flow are usually represented using diagrams. What are some object-oriented artifacts used to document and communicate object relationships? To review, read pages 463-464 of The New Software Engineering.
A convenient way to list the activities of the requirements analysis phase is via a diagram. For example, to list the activities for object-oriented requirements phase, the following diagram is useful:
Inputs to the phase are on the left side and outputs are on the right side. Control elements are listed above the box, and typically include policies, processes, procedures, plans, and constraints.
Resources, support, and tools are listed below the box. Activities are written in the box. This diagram format is called IDEF (Integration Definition).
An IDEF diagram for OO Requirements Analysis follows:
Consider data-oriented methods. What are data-oriented requirements analysis activities and artifacts? To review, read Table of Contents, page vii, Chapter 9 sections. The activities of data-oriented requirements analysis are the subsections of Business Area Analysis Activities. They also identify the main data-oriented analysis artifacts. The chapter itself goes into a lot of detail-The New Software Engineering, Business Area Analysis Activities, page 339. The table of contents abstracts to focus just on the names of the activities and the key artifacts.
Consider process-oriented methods. What are process-oriented requirements analysis activities and artifacts? To review, read Table of Contents, page vii, Chapter 7 subsections of Structured Systems Analysis Activities. (Structured Systems Analysis is an example of a Process-oriented method. Structured Systems Analysis Activities are discussed on page 231 of The New Software Engineering.
Unit 5 Vocabulary
This vocabulary list includes terms that might help you with the review items above and some terms you should be familiar with to be successful in completing the final exam for the course.
Try to think of the reason why each term is included.
- Elicitation
- Subsystem
- Method
- Methodology
- Shall
- Functional requirement
- Nonfunctional requirement
- Performance requirement
- System quality requirement
- Constraint requirement
- Interface requirement
- Process diagram or IDEF
- Requirements stakeholders
- Requirements elicitation
- Requirements specification
- Requirements modeling
- Requirements analysis
- Requirements engineering
- Requirements change management
- Traceability
- Validation
- Verification
- Satisfies
- Data-orientation; activities and artifacts
- Process-orientation: activities and artifacts
- Object-orientation: activities and artifacts