UML Weekend Crash Course™ - To Parent Directory

SESSION
4
Defining Requirements
for the Case Study
Session Checklist
✔ Explaining the concept of a problem statement
✔ Identifying types of requirements
✔ Explaining the process of gathering requirements
✔ Identifying common pitfalls in requirements gathering
In this session, you begin work on the case study. The case study is a scaled down inventory
control system. In a software project, as with many other problem-solving endeavors,
the first step is to gather as much relevant information as possible. In most
projects, you call this gathering requirements. But what kind of requirements do you need to
build software
The Case Study Problem Statement
To make all this talk of requirements and pitfalls a bit more realistic, I focus on a sample
problem, the case study. Your goal is to gather enough information about the system to
rewrite it by evaluating the problem statement. Typically, in order to start a project, there
has to be a perceived problem to solve (or an opportunity to exploit). Users and/or management
see something about the existing system as an obstacle to the goals of the company.
In the case of a new business, the “problem” may be the lack of a system to do a critical
function. The problem statement documents this perception.
The problem statement for your case study consists of the following four paragraphs
titled receiving, stocking, order fulfillment, and shipping. Refer back to these paragraphs as
you discover what kind of questions to ask to gather the requirements. For this chapter, you
simply gather the requirements in the form of textual descriptions, that is, answers to questions.
In the remaining sessions, you find out how to formalize these requirements using
the UML diagrams.