Unit 5: Fundamentals of Requirements Analysis
Requirements elicitation is when software engineers interact with the stakeholders, including users, to gather information about what the software system needs to do. In this unit, we examine what the software engineer does to elicit, analyze (or translate), validate, and manage this life cycle phase. Each step requires working with the customer to achieve a common understanding of the customer's goals. This set of activities is called "analysis" and focuses on what the application will do, whereas "design" describes how the application will work.
There are many ways to elicit and analyze customer requirements. The three most commonly used methodologies are data-oriented, process-oriented, and object-oriented. We will examine the conceptual foundations, activities, and deliverables in each of these methodologies. As you review this unit, focus on the object-oriented methodology and how it applies to software requirements and analysis. You will put it all together later in this course as part of a case study.
Completing this unit should take you approximately 4 hours.
Upon successful completion of this unit, you will be able to:
- interpret fundamental software requirements and analysis terms, such as actors, constraints, and use cases;
- apply each of the main activities of software requirements analysis, such as gathering, specification, and verification;
- describe the conceptual foundation underlying data-oriented, process-oriented, and object-oriented methodologies; and
- describe the analysis activities and their major representations in data-oriented, process-oriented, and object-oriented methodologies.
5.1: Requirements Fundamentals
This section reviews the requirements terms, concepts, and models presented in earlier units.
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.
5.2: The Requirements Process
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.
5.3: Conceptual Modeling
Generally, three model types for software engineering are presented in this course: process-oriented, data-oriented, and object-oriented. They have similar processes but different perspectives and emphases concerning data and activities. Since the OO model incorporates aspects of the other two, it is presented in this section.
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.
5.4: Use Case Diagrams
Use case and sequence diagrams are two key OO modeling diagrams for identifying and communicating requirements. This section explains and illustrates them by creating examples for the Post system.
The use case is the first key OO modeling diagram discussed for application in the requirements phase of the SDLC. Use cases are a powerful way of modeling what the system needs to do. "Actors" are key in capturing requirements; the following section elaborates on their use in requirements 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.
5.5: Sequence Diagrams
The second key OO modeling diagram discussed for application in the requirements phase of the SDLC is the sequence diagram. Both use cases and sequence diagrams are behavioral types of diagrams.
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.
Unit 5 Assessment
- Receive a grade
Take this assessment to see how well you understood this unit.
- This assessment does not count towards your grade. It is just for practice!
- You will see the correct answers when you submit your answers. Use this to help you study for the final exam!
- You can take this assessment as many times as you want, whenever you want.