Requirements Determination and Requirements Structuring

By Zhenyu Zhu


Requirements determination and requirements structuring are two core components of system analysis. Traditionally, interviewing, questionnaires, directly observing and analyzing documents are four main methods adopted by system analysts to collect information. JAD and prototyping are two modern requirements determination methodologies, which are developed and based on the previous traditional methods. A well-structured representation of system requirements can dramatically improve the communication among analysts, designers, users, and programmers. DFD, structured English, decision tables, decision trees, and E-R diagrams are traditional primary requirements structuring tools. Nowadays, RAD and OOA are emerging to help streamline and shorten the total SDLC. While RAD SDLC packs traditional analysis phase and part of design phase into one step [21] , OOA tries to make the outcomes of analysis phase can be reused by the following developing phases.


         Analysis is the first SDLC phase where we begin to understand, in depth, the needs for system. System analysis involves a substantial amount of effort and cost and is therefore undertaken only after management had decided that the systems development project under consideration has merit and should be pursed through this phase. Most observers would agree than many of the errors in developed system are directly traceable to inadequate efforts in the analysis and design phases of the life cycle. Industry studies show that 56% of systems problems are based on poor requirements definition, as opposed to 7% that are caused by poor coding. In the maintenance arena, 82% of the effort is due to poor requirements as opposed to 1% for poor coding.[1] However, for many reasons, it is difficult to obtain a correct and complete set of   requirements. [12]

              As analysis can be divided into three main activities: Requirement determination, Requirements Structuring, and Alternative generation and selection. The third one is usually regarded as the automatic result from the first two processes. So, in this article, I focus on requirements determination and requirements structuring.

       Requirements determination is the beginning sub phase of analysis. In this sub phase, analysts should gather information on what the system should do from as many sources as possible. There are some traditional methods to help collecting system requirements, such as interviewing, survey, directly observing users, etc. Nowadays, some modern requirements colleting methods, such as JAD and prototyping, emerged.

       Requirements structuring is the process to use some kind of systematical and standard, well-structured methods to model the real world. Traditionally, we use data flow diagram for process modeling, decision table or decision tree for logic modeling, and Entity-relationship diagram for data modeling. These modeling tools usually separately model only one face of the real world. So, when we try to show the integral picture of a system, we usually choose more than one of the above requirements structuring methods.

       Rapid Application Development (RAD) is an approach that promises better and cheaper systems and more rapid deployment by having system developers and end users work tighter jointly in real-time to develop systems. Usually, RAD allows usable systems to be built in as little as 60-90 days. [14] RAD is not a single methodology but is more a general strategy of developing information systems. It brings several system development components together. Nowadays, a lot of RAD tools are available, such as VB for windows application, MBBuilder for MapInfo MapBasic. [16,17]

       Object-oriented analysis and development is a brand new methodology. Although OOP has become popular in computer world, whether OOA is superior to traditional methods is still a question mark. However, from the view of OO world, OOA seems having an important role to play in the future.

       The objectives of this article are to introduce some widely adopted basic requirements determination and requirements structuring methods, compare and contrast those methods and try to find a best way for system requirements analysis.

Requirements Determination

Collection of information is at the core of systems analysis. Information requirement determination (IRD) is frequently and convincingly presented as the most critical phase of information system (IS) development, and many IS failures have been attributed to incomplete and inaccurate information requirements. [13] System analysts must collect the information about the current system and how users would like to improve their performance with new information system. Accurately understanding the users’ requirements will help the system developing team deliver a proper system to the end users in limited time and limited budget. If user just wants an “ant”, definitely, an “elephant” is improper. There are many methods to collect information. This article will discuss some basic and widely adopted ones of them.

Interviewing is one of the primary ways to gather information about an information system. A good system analyst must be good at interviewing and no project can be conduct without interviewing. There are many ways to arrange an effectively interview and no one is superior to others. However, experience analysts commonly accept some following best practices for an effective interview:

n         Prepare the interview carefully, including appointment, priming question, checklist, agenda, and questions.

n         Listen carefully and take note during the interview (tape record if possible)

n         Review notes within 48 hours after interview

n         Be neutral

n         Seek diverse views

Questionnaires have the advantage of gathering information from many people in a relatively short time and of being less biased in the interpretation of their results. Choosing right questionnaires respondents and designing effective questionnaires are the critical issues in this information collection method. People usually are only use a part of functions of a system, so they are always just familiar with a part of the system functions or processes. In most situations, one copy of questionnaires obviously cannot fit to all the users. To conduct an effective survey, the analyst should group the users properly and design different questionnaires for different group. Moreover, the ability to build good questionnaires is a skill that improves with practice and experience. When designing questionnaires, the analyst should concern the following issues at least:

n         The ambiguity of questions.

n         Consistence of respondents’ answers.

n         What kind of question should be applied, open-ended or close-ended?

n         What is the proper length of the questionnaires?

The third one is directly observing users. People are not always very reliable informants, even when they try to be reliable and tell what they think is the truth. People often do not have a completely accurate appreciation of what they do or how they do it. This I especially true concerning infrequent events, issues from the past, or issues for which people have considerable passion. Since people can not always be trusted to reliably interpret and report their own actions, analyst can supplement and corroborate what people say by watching what they do or by obtaining relatively objective measures of how people behave in work situation. However, observation can cause people to change their normal operation behavior. It will make the gathered information biased. [21]

The fourth one is analyzing procedures and other documents. By examining existing system and organizational documentation, system analyst can find out details about current system and the organization these systems support. In documents analyst can find information, such as problem with existing systems, opportunities to meet new needs if only certain information or information processing were available, organizational direction that can influence information system requirements, and the reason why current systems are designed as they are, etc. [21]

However, when analyzing those official documentations, analysts should pay attention to the difference between the systems described on the official documentations and the practical systems in real world. For the reason of inadequacies of formal procedures, individual work habits and preferences, resistance to control, and other factors, the difference between so called formal system and informal system universally exists.

The fifth one is Joint Application Design (JAD). JAD is a facilitated, team-based approach for defining the requirements for new or modified information systems. JAD is started at IBM in the late 1970s. The main idea behind JAD is to bring together the key users, managers, and system analysts involved in the analysis of a current system. The primary purpose of using JAD in the analysis phase is to collect systems requirements simultaneously from the key people involved with the system. The result is an intense and structured, but highly effective, process. Having all the key people together in one place at one time allows analysts to see where there are areas of agreement and where there are conflicts. [2,21]

The typical participants in a JAD are: JAD session leader, end users, business managers, sponsor, system analysts, IS staff, scribe, etc. The JAD team is a group of from six to sixteen individual who all have a stake in designing a high quality system. Approximately two thirds of the group members are functional experts the other one third are systems professionals. [2]  JAD sessions are usually conducted in a location other than the place where the people involved normally work, and are usually held in special purpose rooms where participants sit around horseshoe-shaped tables. Involving so many different kinds of people in one workshop makes how to effectively and efficiently organize the JAD session a big challenge. [4,5]

When a JAD is completed, the final result is a set of documents that detail the workings of the current system related to study of a replacement system. These requirements definition document generally includes business activity model and definitions, data model and definition, data input and output requirements. It may also include interface requirements, screen and report layouts, ad hoc query specifications, menus, and security requirements. When used at a later point in the system development life cycle, a JAD session can also be used to refine a system prototype, develop new job profiles for system users, or develop an implementation plan. [2]

However, to exploit full potential of JAD, the groupware tools should be applied in JAD workshop sessions. The use of groupware tools to support the joint Application Development technique increases the value of this technique dramatically. When groupware tools are used in an automated JAD workshop, they greatly facilitate the generation, analysis, and documentation of information. This is particularly valuable for JAD workshops conducted to define and build consensus on the requirements for new systems. [3]

The Sixth one is Prototyping. Prototyping is a means of exploring ideas before you invest in them. Most system developers believe that the benefits from early usability data are at least ten times greater than those from late usability data. [19,20] Prototyping allow system analysts quickly show users the basic requirement into a working version of the desired information system. After viewing and testing the prototype, the users usually adjust existing requirements to new ones. The goal with using prototyping to support requirement determination is to develop concrete specification for the ultimate system, not to build the ultimate system from prototyping. Prototyping is most useful for requirements determination when user requirements are not clear or well understood, one or a few users and other stakeholders are involved with the system, possible designs are complex and require concrete form to fully evaluate, communication problems have existed in the past between users and analysts, and Tools and data are readily available to rapidly build working systems, etc. [21]

When adopting prototyping, analysts should concern about the potential problems about this requirements determination method, such as informal documentation, ignored subtle but important requirements, etc.

            When we choose requirements determination method for a specific project, there seven characters of them we should consider. They are Information Richness, Time Required, Expense, Chance for Follow-up and probing, Confidentiality, Involvement of Subject, Potential Audience. Table 1 concludes these characters of previously discussed six requirements determination methods.

Table 1





Document analysis



Information Richness


Medium to low


Low (passive) and old


Medium to High

Time Required

Can be extensive

Low to moderate

Can be extensive

Low to moderate

Dedicated period of time of all kinds of involved people

Moderate and can be extensive


Can be high


Can be high

Low to moderate



Chance for Follow-up and probing








Interviewee is known to interviewer

Respondent can be unknown

Observee is known to interviewer

Depends on nature of document

All the people know each other

Usually know each other

Involvement of Subject

Interviewee is involved and committed

Respondent is passive, no clear commitment

Interviewees may or may not be involved and committed depending on whether they know if they are being observed

None, no clear commitment

All kinds of people are involved and committed

Users are involved and committed

Potential Audience

Limited numbers, but complete responses from those interviewed

Can be quite large, but lack of response from some can bias results

Limited numbers and limited time of each

Potentially biased by which documents were kept or because document not created for this purpose

Potentially biased by the subordinator intentionally don’t want to directly point out his superior’s errors. 

Limited numbers; it is difficult to diffuse or adapt to other potential users



Requirements Structuring:

In the last section, we discuss about the methods to determine information system requirements. In this section, we will focus on the widely adopted methods used to present the requirements. Traditionally, there are three basic methods for requirements structuring:

First, a data flow diagram (DFD) is a graphical tool that allows analysts (and users) to depict the flow of data in an information system. DFD graphically representing the functions, or processes, which capture, manipulate, store and distribute data between a system and its environment and between components within a system. The final deliverables and outcomes for DFD are: [21]

·         Context data flow diagram, which defines the boundary of the system

·         DFDs of current physical system, which is used to determine how to convert the current system into its replacement.

·         DFDs of current logical system

·         DFDs of new logical system

·         Thorough descriptions of each DFD component

In a DFD, there are only four symbols that represent the same things: data flows, data stores, processes, and source/sinks (or external entities). A data flow can be best understood as data in motion, moving from one place in a system to another. A data store is data as rest, which may take the form of many different physical representations. A process is the work or actions performed on data so that they are transformed, stored, or distributed. Source/sink is the origin or destination of data, sometimes referred to as external entities.

Data flow diagrams should be mechanically correct, but they should also accurately reflect the information system being modeled. To that end, analyst should check DFDs for completeness and consistency and draw them as if the system being modeled were timeless. Complete sets of DFDs should extend to the primitive level where every component reflects certain irreducible properties. Following above guidelines, DFDs can aid the analysis process by analyzing the gaps between existing procedures and desired procedures and between current and new systems. [21]

Second, logic Modeling involves representing the internal structure and functionality of the processes represented on data flow diagrams. In the analysis phase, logic modeling will be complete and reasonably detailed, but it will also be generic in that it will not reflect the structure or syntax of a particular programming language. There are three traditional tools for logic modeling: structure English, decision tables and decision trees. Structured English is modified form of the English language used to specify the logic of information system processes. Although there is no single standard, structured English typically relies on action verbs and noun phrases and contains no adjectives or adverbs. Decision table is a matrix representation of the logic of a decision, which specifies the possible conditions for decision and the resulting actions. Usually, there are there parts in a decision table: the condition stubs, the action stubs, and the rules. A decision tree is a graphical technique that depicts a decision or choice situation as a connected series of nodes and branches. Decision trees have two main components: decision points and actions. Nodes represent decision points, while actions are represented by oval. The comparison among these three is showed in following table 2:

Table 2


Structured English

Decision Table

Decision Tree

Determining conditions & actions

Second Best

Third Best


Transforming conditions & actions into sequence


Third Best


Checking consistency & completeness

Third Best




The comparison between decision table and decision trees is shown in table 3. [21]

Table 3


Decision Tables

Decision Trees

Portraying complex logic



Portraying simple problems



Making decisions



More compact



Easier to manipulate




Third, data modeling develops the definition, structure, and relationships within the data. Many analysts believe that a data model is the most important part of the statement of information system requirements. This belief is based on following reasons:

 The most common format used for data modeling is entity-relationship (E-R) diagramming. E-R data model is a detailed, logical representation of the data for organization or for a business area. There are three main constructs in E-R diagram: data entities, relationships, and their associated attributes. An entity is a person, place, object event, or concept in the user environment about which the organization wishes to maintain data. Each entity type has a set of attributes associated with it. An attribute is a property or characteristic of an entity that is of interest to the organization. Relationships are the glue that holds together the various components of an E-R model. A relationship is an association between the instances of one or more entity types that is of interest to the organization.

Advanced system analysis:

Nowadays, there are other two very widely adopted methods for system analysis. They are Rapid Application Development (RAD) and Object-Oriented analysis. These two are always labeled as advanced system analysis or modern system analysis. The popularity of these two methods owes to the high pressure of today’s quickly changed business environment. The present end-users cannot wait for two to three years to have a system. So, streamlining the SDLC and shortening the total SDLC play a critical role in system development. To achieve this goal, RAD tries to compact several phases into one single step while OOA try to make the analysis phase seamlessly pass to OO design phase.

RAD is an approach to developing information systems that promises better and cheaper systems and more rapid deployment by having systems developers and end users work together jointly in real time to develop. RAD grew out of the convergence of two trends [10, 21] 

Comparing with seven phases standard SDLC, RAD SDLC has only four phases. They are planning, design, development, and cutover. RAD pushes analysis and part of design jobs of standard SDLC into one design step. Actually, RAD is not a single methodology but is instead a general strategy of developing information systems, which takes account human factors and corporate culture as well as technology. [11] To succeed, RAD relies on bringing together several system development components, such as JAD, prototyping, and all kinds of traditional requirements structuring methods. [9] It is impossible to do so without using the high-powered computer-based tools such as visual tools and integrated CASE tools, which include code generators for creating code from the designs end users and analysts create during prototyping. According to Martin, there are four necessary pillars for RAD approach: tools, people, methodology, and management.

Advantages of RAD: [21]

Disadvantages of RAD: [21]

In one sentence, RAD heavily depends on JAD and Prototyping, so it inherits the advantages of these two approaches while it has to tolerate the disadvantages of the two. [9] Last but not the least, the RAD approach is not appropriate to all projects Project scope, size and circumstances all determine the success of a RAD approach. [15]

         Object-orient system analysis abstracts concepts from the application domain and describes what the intended system must do, rather than how it will be done. Instead of using functional decomposition of the system, the OOA approach focuses on identifying objects and their activities. Using the Object-oriented approach, system analysts model information systems by identifying a set of objects, along with their attributes and operations that manipulate the object data. Objects are grouped into classes that have common properties. Classes are organized into hierarchies, in which the subclasses inherit the properties, including the data definitions and operations. [6,18] The model specifies the functional behavior of the system, independent of concerns relating to the environment in which it is to be finally implemented.

        The OO analysts need to devote sufficient time to clearly understand the requirements of the problem and the analysis model should capture those requirements completely and accurately. The core of OO is reusability. The whole OO system is built on inheritance, so a subtle misunderstanding of the basic requirements of the problem may cause the whole system seems ridiculous. OOA is inspired by nowadays very popular object-orient programming (OOP). The traditional system analysis methods cannot adapt to OOP to make the whole development process smoother and seamless, so OOA comes up and tries to solve such problem. [7] The outcomes of OOA usually are considered reusable for further OO system development phase, such as OOD and OOP, and this reusability characters can dramatically shorten the total SDLC.

OOA has it own whole set of modeling tools to represent the system requirements. They are:

The commonly admitted points about OOA advantages in OO world are [8, 21] :

So far, although more and more system analysts adopt OOA, whether it is superior to traditional system analysis is still in hot arguing. Although in OO world, the above advantage points about OOA are commonly accepted, there are still a large number of software communities don’t agree with them. [8] Dr.vicky L.Sauter said people may more naturally think with a procedure way than with an object way. Moreover, it is commonly accepted in the Object-oriented research field that the methodology of OOA is far from mature and the identification of object classes remains an art because it is highly dependent on the problem domain. [6]






No official best way to system analysis, the methods applied to the project depend on the project context, such as analyst’s expertise, user’s favorites, project’s size, project’s complexity, etc. So, a good system analyst should be able to use any of these methods on the fly according to specific project context.

Although the new system analysis methods come out one by one, the traditional ways for requirements determination, like interviewing, questionnaires, directly observing, and analyzing documents can never be simply replaced. Further more, neither in modern requirements determination methods, such as JAD and prototyping, nor in nowadays advanced system analysis, such as RAD and OOA, those four types of information collecting approaches are always the cornerstones, which can never touched.

As the result of high business environment pace changing, RAD show itself at dramatically shorten the SDLC. However, from the view of a system requirements analysis, RAD intensively combines all kinds of system analysis methodologies into one-step process by using nowadays high-powered computer technology. RAD heavily adopts JAD and prototyping as the two primary ways to gather the requirements, so the merits and drawbacks of these two methods also can be found in RAD.

OOA may be the real revolution in system analysis field. However, such revolution just happened at the requirements structuring level. It does not touch the basic requirements determination methods, although better requirements representation can help requirements determination process more efficient and effective. In order to adapt to the OOP, a whole set of OOA requirements structuring tools, such as use-case diagram, class diagram, etc, were developed, which are thoroughly different to the traditional requirements structuring tools, such as DFD, structured English, etc. So far, whether the OOA is better than the traditional analysis methods or not is still a question mark. However, traditional requirements analysis techniques were inspired by, and founded on, structured programming concepts. Nowadays, in a programming world that is increasingly turning to object orientation, such traditional techniques seemed out of date and had to be replaced.[7]




[1] JAD to the rescue

  Matthews, JoyComputerworld. Framingham:  Dec 4, 1995. Vol. 29, Iss. 49;  pg. 93, 1 pgs

[2] JAD basics

AnonymousJournal of Systems Management. Cleveland:  Sep/Oct 1995. Vol. 46, Iss. 5;  pg. 18, 1 pgs

[3] Using groupware tools to automate Joint Application Development

Leventhal, Naomi SJournal of Systems Management. Cleveland: Sep/Oct 1995.  Vol. 46, Iss. 5;  pg. 16, 6 pgs

[4] Coping with JAD
Kelly, David A. Computerworld. Framingham: Oct 24, 1994. Vol. 28, Iss. 43; p. 123 (1 page)

[5] Why JAD goes bad
Garner, Rochelle. Computerworld. Framingham: Apr 25, 1994. Vol. 28, Iss. 17; p. 87 (2 pages)

[6] Two MIS analysis methods: An experimental comparison
Wang, Shouhong. Journal of Education for Business. Washington: Jan 1996. Vol. 71, Iss. 3; p. 136

[7] From object-oriented to goal-oriented requirements analysis
John Mylopoulos. Association for Computing Machinery. Communications of the ACM. New York: Jan 1999. Vol. 42, Iss. 1; p. 31

[8] The ups and downs of object-oriented systems development
Richard A Johnson. Association for Computing Machinery. Communications of the ACM. New York: Oct 2000. Vol. 43, Iss. 10; p. 68

[9] Systems analysis
Chris Chmielewski. Mortgage Banking. Washington: Feb 1998. Vol. 58, Iss. 5; p. 111

[10] Rapid-fire re-engineering
Seybold, Patricia B. Chief Executive. New York: Sep 1995. p. 68

[11] Planning, testing, teamwork a recipe for quality apps
Adhikari, Richard. Software Magazine. Englewood: Mar 1994. Vol. 14, Iss. 3; p. 41   (last viewed date 12/15/03)

[12] Strategies for information requirements determination  By G. B. Davis  ( last viewed date 12/15/03)

[13] The Use of Stopping Rules in Information Requirements Determination

Mitzi G. Pitts (last viewed date 12/15/03)

[14] RAPID APPLICATION DEVELOPMENT © 1997 by Walter Maner (last viewed date 12/15/03)

[15] Process/Project RAD - RAD - Rapid Application Development Process,1289,2-19516-2,00.html

(Last viewed date 12/15/03)


(Last view date 12/15/03)

[17] Rapid Application Development

Ted Brockwood

(Last viewed date 12/15/03)

[18] Object-Oriented Analysis and Design

By Michael Gora DBMS, May 1996 (Last viewed date 12/15/03)

[19] Paper Prototyping: Getting User Data Before You Code

Jakob Nielsen, April 14, 2003  (Last viewed date 12/15/03)

[20] The Art of UI Prototyping

Scott Berkun, November 2000 (Last viewed date 12/15/03)

[21] Modern Systems Analysis and Design (3rd Edition)
by Jeffrey A. Hoffer (Author), Joey George (Author), Joseph Valacich (Author)