CIS 251 -
System Development Methods
Chapter 4: Requirements Modeling
This lesson discusses material from chapter 4. Objectives important to
- Systems analysis phase
- JAD, RAD, and Agile methods
- Functional decomposition diagram (FDD)
- Unified Modeling Language (UML) and Use Case diagrams
- Outputs, inputs, processes, performance standards, and control standards
- Total Cost of Ownership (TCO)
- Conduct a successful interview
- Develop effective documentation methods to use during systems development
- Project management
- Assignments for the week
The chapter begins with statement about where we are. This chapter begins the analysis section of the text, and it addresses requirements modeling, which is about determining what the users need from the system. The authors try to lighten the mood with a Dilbert cartoon about a project that has no requirements. Insight: this means you are interviewing the wrong user.
The text makes a point of referring to this chapter's topic as modeling business requirements , instead of another common term, user requirements. This may be to point out that users are only one kind of stakeholder whose requirements your system must meet.
There are several categories of requirements that must be documented, and addressed by your system:
In the classic approach, you determine the outputs of the system first, typically focusing on the reports it must generate. This information should lead to the next two bullets at the same time: what data must we collect (inputs), and how must it be processed to generate those reports? It is a poor system that does not out-perform its predecessor, so you should assume that is one of the requirements under performance. It is unlikely to be the only one. Finally, under security, how must the data and information be protected from anyone who is not supposed to have access to it?
The text has mentioned JAD, RAD, and Agile methods in every chapter so far. It discusses them in a bit more detail in this chapter.
JAD - Joint Application Development
The text makes its case, again, for involving users in the project.
Users must approve and use a system, so they should contribute to the
development of it. Six team member types and roles on a JAD team are
listed on page 106. Some roles may overlap:
- JAD project leader - a facilitator of team work sessions, a guide to eventual solutions
- Top management - may not be members of the actual team, but must provide authorization of the project at the enterprise level
- Managers - provide goals for the system based on their level of authority, and their understanding of business processes and system requirements
- Users - provide input about the old system (if any), what they need from the new system, their reasons for the requested change
- System analysts (and other IT staff) - the text does not spell out that these are the people who build the system; they offer a technical perspective when gathering requirements, and advice about options for the five bullets above based on team discussions
- Recorder - documents work sessions; may be any member of the team, may be a rotating position, should be reserved for IT members of the team
The "typical agenda" shown on page 135 is really only typical of an initial session. Most of these actions would only take place at the outset of a project.
The text observes that a JAD approach can be cumbersome (slow) when the team is too large. This is probably true of any team approach. This is now a classic approach used by IT organizations.
RAD - Rapid Application Development
Another team approach, this time focused on speed of development is
RAD. The text states that a JAD group is focused on creating
a requirements model, while a RAD group has the new
system as its goal. It is not that cut and dried in the real world.
You may find that the same people who develop requirements continue
to meet with the system developers (IT staff) as prototypes of each
part of the system are designed, built, and tested.
The text discusses characteristics of agile development: prototyping,
demos to users, feedback from users to adjust the prototypes. I am hard
pressed to see any difference between this description and the chart
on page 108 depicting phases of a RAD project. It reminds me of the
fanatic devotion shown by fans of Coca-Cola and Pepsi. The reality is
that each brand has several varieties that have come to be more alike
than they are different, as years have gone by and formulas have changed.
I see more reason to argue about Coke or Pepsi than to worry which methodology
we are using to create our new system. We will leave the discussion
of commitment to CASE tools, dedication to whiteboards and sticky notes,
and calling each other pigs or chickens to those who are capable of
practicing such foolish notions.
The text continues with a discussion of some tools used for requirements modeling. These tools are meant to be less technical than tools used to generate code to make this phase more accessible to non-technical users who will be involved.
- Modeling tools in CASE applications
- Functional Decomposition Diagrams - a diagram that is shaped like an organization chart; it starts at a high level, describes areas of functionality, and breaks them into more specific functions (business processes) that can be programmed as modules in the new system
- Business Process Model - a model that focuses on one or more business processes; meant to fit into a repository of such models
The example shown in figure 4-9 is not clear because
it is not complex enough. This is usually called a
lane model. In such a model, the chart is like a swimming
pool. The vertical axis shows participants
in the process, as though they were competing swimmers on blocks, waiting
for a race to start. That is where the analogy breaks. These swimmers
do not compete. They all participate in processing
a request, a task, or a series of actions that depend on each other.
One entity starts the process, then hands off
to the next (indicated by arrows), and so on until the process is completed,
more like a relay race than like a swim meet. Unlike a relay race, entities
may hand off back and forth in some processes. This kind of chart may
be used to show how a business process is presently done, or how it
will be done in the new system.
- Data Flow Diagrams - drawn more like programming flow charts; shows how data flows into the systems, where it is stored, what processes receive/retrieve/process/store it
- Use Case Diagrams - Simple diagrams that use stick figures for users, folders for systems, and ellipses for processes in the system; meant to show which users interact with which processes to provide input or obtain output; uses Unified Modeling Language
For a few pages, the text offers examples of system output, input, processes, performance standards, and control standards. Review these for any ideas you have not seen in other classes.
A person involved in a system project should be aware of the reasons for the project. A common reason is that the system you are replacing was not scalable, or not scalable enough, and is not up to the enterprise's present or future needs. As such, scalability should be a feature that all system developers would try to put into their new systems.
It may be hard to see why the last system had the shortcomings you will encounter. To quote Robert Heinlein, when the question begins "why do they" or "why don't they" the answer usually involves money. As the year 1999 was ending, I was aware of several systems that needed updating for reasons that were based in the fact that their developers never thought that their systems would be used for more than a few years. Because the systems were supposed to be short lived, the developers scrimped on data storage and memory use, and only collected one or two digits for a year, instead of four. As such, the systems needed updates before the year 2000 ruined any date calculations they would need to continue doing. They were not scalable in the sense that they could not accommodate a new variation in user input (dates after 1999) beyond what their designers expected.
Systems should be designed to accommodate growth, changes in data structures, more users, more customers, and more products than are currently part of the reality.
Total Cost of Ownership includes initial
and ongoing costs associated with any product, including
information systems. The text points out that a system may have indirect
costs, which are discussed in more detail in section C of the Toolkit.
Turn to page 499, and consider the discussion of costs and benefits.
Let's move ahead to the Toolkit section about Cost Classifications
starting on page 500. Some of these classifications overlap.
- tangible costs - a tangible asset is one that you can see, feel, touch, and more importantly, buy and sell
- intangible costs - morale, attitude, satisfaction, and good will are examples of intangibles that may add cost or value to your project
- direct costs - costs for the development of a system, acquisition of hardware and software, salaries for developers and other development team members, lost productivity for staff who would be otherwise productive while they are on the development team
- indirect costs - ongoing support costs, insurance changes, costs to administer the system after it is installed, maintenance, consulting fees with the contractor who is the only one who understands the system
- fixed costs - predictable costs, such as rent, fees for web space and domain names, salary and benefits for new staff (even though they change over time, they remain the same for longer periods)
- variable costs - the cost of consumables like paper, electricity, and cell phones that can vary each month
- development costs - expenses that are part of the development project, that end with the project or when the system is installed
- operational costs - ongoing costs after the project is over
Costs and benefits should be considered before the project is started, and as an ongoing measure of the project's feasibility.
Back to chapter 4 and requirements. The text describes a fact finding
process, to determine what the old system does, what
the new system must do, who the users
are and will be, when each person should interface with
the system, and so on. Consider the chart in figure 4-16, that provides
a framework of questions to ask the people in your JAD or RAD group. These
are not the only questions to ask. The answers to each
question offered in the text may prompt you to ask more questions. The
text assumes that you will be working in sessions like these, and conducting
interviews with stakeholders as needed. Direct personal involvement, as
opposed to surveys or web based input, is preferred.
- As the text points out on page 119, the first step in conducting successful
interviews is to decide who to interview. Ask whether
the organization has a functional organization chart
as well as a formal one. Finding the people who actually do or will
work with your system is critical.
- The interview must have objectives. If you lose track of why you are interviewing staff, you will waste their time and yours. Remember to remain flexible as well. You may learn something in an interview that will change your project.
- Specific interview questions are needed that find whatever information you need. The text warns against asking leading questions, which is good advice when fact finding. Ask open questions, allowing the subject to elaborate when you are not sure you have all the facts. Ask very specific questions to clarify known issues. The text recommends range-of-response questions to get better data for analysis. Watch out for this method. It can lead you to the wrong result when you are asking the wrong question. It runs the risk of being another type of leading question, which can produce a response the subject thinks is acceptable.
- The text tells us to prepare for the interview by making appointments and telling the subjects what will be discussed. It does not mention that you must make your position in the project clear, and your legitimate need to conduct the interview. Without that, the people you are seeking to interview might suspect your invitation to be spam.
- When you conduct an interview, pay attention to the subject. The text warns against looking only for the answers you expect. Look for the answers that are being given, both in words and in body language.
- Document the questions and answers from the interviews. If it doesn't get recorded, you may as well not have done it.
- The text tells us to evaluate the interviews. This is often done best as a team activity. You may notice patterns of responses when evaluating interviews conducted by several members of your team that you could miss if you only look at your own collected data.
The text reviews some other fact finding methods such as observation, questionnaires, and surveys. Each can be helpful, depending on the type of information you are looking for. When possible, however, you should always prefer to form a work group of representative stakeholders, which is much more likely to find whatever truths you need for your system.