CS302: Software Engineering

5a. Interpret fundamental software requirements and analysis terms, such as actors, constraints, and use cases

• What are the 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?
• What roles work with or use software requirements?
• What are some other attributes of the requirements?

Software requirements analysis aims to specify the problem to be solved or a task to be performed by the software. Second, remember that software may be a subsystem of a larger system, and therefore, the software requirements are subproblems or subtasks of the larger system. Third, software requirements analysis identifies what the software system will do, not how it will do it. OO analysis describes requirements with use case diagrams supplemented with textual information. A use case represents a functional requirement, the actor or role that uses the system by interacting with it via an exchange of information, and constraints that limit the system's behavior. 

We elicit requirements using the data-gathering techniques. Requirements can be functional or non-functional. A functional requirement specifies what the software shall and shall not do. Performance, interface, design, and development standards are non-functional requirements. We write requirements as simple, concise, unambiguous shall statements in a requirements model using diagrams such as use cases and text that express the types and properties of data. The requirements model is the starting model for software development, transformed into models of other life-cycle phases. 

The requirements statements or model is analyzed to determine the attributes of the requirements. We use attributes to determine the quality of the requirements, such as whether the requirements are complete, consistent, traceable, and so on. Complete means that the requirements address all of the needs of the customer or client; consistent means that there are no contradictions between 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, and with management elements. Traceable means that the connection between the requirements, system requirements, design, implementation, and management elements has documentation. We need traceability to software and system tests for validation. 

A requirements engineering role is responsible for the requirements. Requirements have many stakeholders, including customers, software designers, and testers. Name some other stakeholders. We use requirements to validate the software system, design, and 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, approving, and controlling changes to requirements. 

To review, see Review of Fundamentals of Requirement Analysis.

5b. Apply the main activities of software requirements analysis, such as gathering, specification, and verification

• How are requirements obtained?
• What are the main activities of the Requirements Phase?

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 application. Selecting several data collection techniques with complementary strengths helps maximize the effectiveness and efficiency of data collection.

What is unique about the data for requirements that make it different from 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 (such as from other projects or systems) and will add to it. Second, requirements elicitation will likely have the most significant 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 and how the software will perform the computation. 

The Requirements Phase of a life-cycle development model corresponds to the problem-definition problem-solving stage. A critical step in solving a problem is to thoroughly understand the problem by collecting relevant data, analyzing the data, concisely specifying the problem, and validating the problem specification. For software engineering and the requirements phase of a life-cycle development, these steps are 1) elicit requirements, 2) analyze the requirements, 3) specify them, and 4) verify and validate them. A process describes each step and uses an object-oriented analysis method for execution.

To review, see The Requirements Process.

5c. Describe the conceptual foundation underlying data-oriented, process-oriented, and object-oriented methodologies

• What methods and methodologies guide the requirements phase activities and produce software requirements?
• How do requirements methods help produce the requirements specification?

Process-oriented methods view a system as a hierarchy of processes related by decomposition. A system performs a process, has inputs, and produces outputs. We can decompose a system into component systems (subsystems), each having inputs and outputs at the next level. The decomposition continues until we reach elementary components that cannot decompose.

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 guide the definition of an initial process model, data model, or object model, respectively, of the problem domain. Depending on the methodology, this initial model helps specify reasonable requirements for processes, data, or objects. In later phases, the methods guide the transformation of the initial model to a solution model for the respective method. 

To review, see Conceptual Modeling.

5d. Describe the analysis activities and their major representations in data-oriented, process-oriented, and object-oriented methodologies

• What are the significant representations used in analysis activities?
• What are the analysis activities used in requirements analysis?

Object-oriented analysis activities are part of the requirements phase. It identifies those objects, processes, attributes, and classes. It assigns processes (methods) to the objects and defines the attributes (data for objects and properties for processes). We typically represent these elements using tables and text. We represent relationships between objects and object classes, intra-object control, and inter-object event processing flow.

A convenient way to list the activities of the requirements analysis phase is via a diagram. For example, the following diagram is functional to list the activities for the object-oriented requirements phase:

Inputs to the phase are on the left side, and outputs are on the right side. We list control elements above the box, including policies, processes, procedures, plans, and constraints. We list resources, support, and tools below the box. We write activities in a box as verbs. This diagram format is called Integration Definition (IDEF). It is a general diagram used in many disciplines to represent process activities. IDEF diagrams, such as the above, can be decomposed into more detailed sub–diagrams. 

Object-oriented methods encompass data-oriented and process-oriented methods, artifacts, and activities. Data-oriented requirements analysis activities and artifacts are data elements resulting from decomposing "problem space" data. Data-oriented requirements analysis is a subsection of a business area analysis. They also identify the main data-oriented analysis artifacts. Process-oriented requirements analysis activities and artifacts result from decomposing the "problem space" functions. Structured systems analysis is an example of a process-oriented method.

To review, see Conceptual Modeling in Object-Oriented Analysis and UML Sequence Diagrams.

Unit 5 Vocabulary

This vocabulary list includes terms you must know to complete the final exam successfully.

• data-oriented methods
• functional requirement
• Integration Definition (IDEF)
• non-functional requirements
• object-oriented analysis
• process-oriented methods
• requirements analysis
• requirements change management
• requirements engineering
• use case