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.
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.
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.
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.
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.
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.
Take this assessment to see how well you understood this unit.