CS302: Software Engineering

Systematic requirements analysis is also known as requirements engineering. Requirements must be measurable, testable, related to identified business needs or opportunities, and defined to a level of detail sufficient for system design. This chapter explains the term requirements analysis and the types and properties of requirements.

This page re-introduces the software requirements process, orienting the five subareas (requirements elicitation, requirements analysis, requirements specification, requirements verification, and requirements management) and showing how the requirements process dovetails with the overall software engineering process.

Requirement analysis is concerned with identifying concepts related to the requirements and creating a conceptual model of the problem domain. A conceptual model shows a static view of associations between concepts. This section reviews OO conceptual modeling and its main components.

Conceptual models are models of entities from the problem domain that are configured to reflect their real-world relationships and dependencies. This section defines requirements, explains requirements analysis, and several types of model diagrams that can be developed. This includes data and control flows, state models, event traces, user interactions, object models, data models, and many others. The model must be selected according to the nature of the problem, the software engineer's expertise, the customer's process requirements, and the availability of methods and tools. The development then transitions from the requirements model to a design model, such that a requirement is allocated to one or more design elements. The section summarizes requirements analysis functions and activities, the use of the requirements, and the products of analysis.

This section goes into more detail on use case diagrams for requirements. What components are in a use case diagram (actors, extensions, stereotypes, and notes)? How are different interactions and features depicted for people who use the application? How are these features mapped into a use case diagram? Remember that a use case diagram cares about "what", not "how". This discussion provides a "big picture" of use cases, their use, and their relationship with "white box" details. These essential elements comprise a use case, rules-of-thumb guidance, the importance of the narrative text connected to a use case diagram, and user stories as an alternative to a use case diagram.

During the requirements analysis phase, the system can be treated as a single "black box", meaning we can look at the system's behavior (what it does) without explaining how it does it. Watch this example of a system sequence diagram for a student admission use case.

System behavior can be described using sequence diagrams. These can help visualize the workflow and how components work with each other. Be sure to understand the main components of a sequence diagram (participants, lifelines, boxes, dividers, and interactions) and how to design it. As you read, remember that the sequence diagram is about "how", not "what". This section includes an example of a sequence diagram and presents sequence diagrams in the context of dynamic diagrams.

Software requirements tools support requirements activities: modeling, analyzing, prioritizing, classifying, managing (planning, scheduling, reviewing, and monitoring), measuring, allocating to design and implementation components, tracing, version and configuration identification and control, and validating. The modeling and diagramming tools, management, measurement, allocation, and configuration management tools are common in each SDLC phase. Formal tools provide support for analysis of correctness, completeness, and consistency; for generation of test cases, use cases, and other UML models; and for translating formal specifications diagrams to requirements specification documents.