Unit 5: Software 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 phase of the life cycle. Each step requires working with the customer to achieve a common understanding of the customer's goals. This set of activities is referred to as "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
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 main features of requirements.
5.2: The Requirements Process
This section introduces the software requirements process, orienting the remaining 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
Requirement analysis is concerned with identifying concepts related to the requirements, and with creating a conceptual model of the problem domain. A conceptual model shows a static view of associations between concepts. This section defines conceptual modeling and reviews the main components of it.
Conceptual models are models of entities from the problem domain that are configured to reflect their real-world relationships and dependencies. This section explains several kinds of models 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 expertise of the software engineer, the process requirements of the customer, and the availability of methods and tools.
5.4: Use Case Diagrams
Use cases are a powerful way of modeling what the system needs to do. Read this section to learn about use case diagrams and how they capture functional requirements.
Find out what components are in a use case diagram (actors, extensions, stereotypes and notes), how to depict different interactions and features for which people use the application and how to map these features into a use case diagram. As you read this section, keep in mind that a use case diagram cares about WHAT, not HOW.
5.5: Sequence Diagrams
- During the requirements analysis phase, the system can be treated as a single "black box", which means that we can look at the system's behavior (what it does) without explaining how it does it. Read this section to see an example of a simplified trace diagram that shows only system input events. This is called a system sequence diagram.
System Behaviour can be described using sequence diagrams. These can help in visualizing 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 this section, keep in mind that sequence diagram diagram cares about HOW, not WHAT.
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.