System Development Methods: Chapter 4

CIS 251 - System Development Methods

Chapter 4: Requirements Modeling

Objectives:

This lesson discusses material from chapter 4. Objectives important to this lesson:

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
Scalability
Total Cost of Ownership (TCO)
Conduct a successful interview
Develop effective documentation methods to use during systems development
Project management
Assignments for the week

Concepts:

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:

outputs
inputs
processes
performance
security

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 134. 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.

Agile Methods

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 136 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 swim 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 602, and consider the discussion of costs and benefits. Here, the text mentions ongoing costs, such as support and maintenance. It mentions a horror story about a $2,000 PC that cost $21,000 over five years. This would be a better story with an explanation of those costs. I know I have not paid anything like that for any of my personal computers.

Let's move ahead to the Toolkit section about Cost Classifications starting on the same page. 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-17, 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 149, 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.