Mangers VS. System Developers on Requirements Analysis

Consider the following dialogue between a systems professional, John Juan, and a manager of a department targeted for a new information system, Peter Pedro:

Juan: The way to go about the analysis is to first examine the old system, such as reviewing key documents and observing the workers perform their tasks. Then we can determine which aspects are working well and which should be preserved.

Pedro: We have been through these types of projects before and what always ends up happening is that we do not get the new system we are promised; we get a modified version of the old system.

Juan: Well, I can assure you that will not happen this time. We just want a thorough understanding of what is working well and what isn’t.

Pedro: I would feel much more comfortable if we first started with a list of our requirements. We should spend some time up-front determining exactly what we want the system to do for my department. Then you systems people can come in and determine what portions to salvage if you wish. Just don’t constrain us to the old system.

Required:

a.Obviously these two workers have different views on how the systems analysis phase should be conducted. Comment on whose position you sympathize with the most.
b.What method would you propose they take? Why?

As a system professional, John Juan’s stand on the first method of acquiring system requirements is mainly through observation so that they could have a thorough understanding of the system. He believes that by observing and understanding the old system, he can get the main requirements needed by the end users who are the workers themselves and not the manager. On his point of view, it is much better to gather requirements on the ‘field of action’ (as I would say) so that he can determine what the significant requirements are and which are not.

As a manager, Peter Pedro’s stand on the first method of acquiring system requirements is giving the system professional the list of requirements and from there make a system out of it. Obviously, he wants a new system that is somehow different from the old one that they are using but still addresses their needs. According to him, their company already encountered a scenario wherein a project was made as a modified version of the old system and not a new one as what has been promised to them. Because of that, he wanted to change the way their company gives system requirements hoping to acquire the ‘new system’ that he really want for their company.

In this scenario, it is clear that both parties have points that they would like to be addressed by the other party. But the question is, who’s position would I sympathize more.

Before I declare whose side I’m on, it is important to know the basics about requirement analysis.

According to THIS website

Requirements Analysis is the process of understanding the customer needs and expectations from a proposed system or application and is a well-defined stage in the Software Development Life Cycle model.

Requirements are a description of how a system should behave or a description of system properties or attributes. It can alternatively be a statement of ‘what’ an application is expected to do.

Given the multiple levels of interaction between users, business processes and devices in global corporations today, there are simultaneous and complex requirements from a single application, from various levels within an organization and outside it as well.

The Software Requirements Analysis Process covers the complex task of eliciting and documenting the requirements of all these users, modeling and analyzing these requirements and documenting them as a basis for system design.
A dedicated and specialized Requirements Analyst is best equipped to handle the job. The Requirements Analysis function may also fall under the scope of Project Manager, Program Manager or Business Analyst, depending on the organizational hierarchy.

Software Requirements Analysis and Documentation Processes are critical to software project success. Requirements Engineering is an emerging field which deals with the systematic handling of requirements.

Why is Requirements Analysis necessary?

Studies reveal that inadequate attention to Software Requirements Analysis at the beginning of a project is the most common cause for critically vulnerable projects that often do not deliver even on the basic tasks for which they were designed. There are instances of corporations that have spent huge amounts on software projects where the end application eventually does not perform the tasks it was intended for.

Software companies are now investing time and resources into effective and streamlined Software Requirements Analysis Processes as a prerequisite to successful projects that align with the client’s business goals and meet the project’s requirement specifications.

Steps in the Requirements Analysis Process

I. Fix system boundaries
This initial step helps in identifying how the new application integrates with the business processes, how it fits into the larger picture and what its scope and limitations will be.

II. Identify the customer
In more recent times there has been a focus on identifying who the ‘users’ or ‘customers’ of an application are. Referred to broadly as the ‘stake holders’, these indicate the group or groups of people who will be directly or indirectly impacted by the new application.
By defining in concrete terms who the intended user is, the Requirements Analyst knows in advance where he has to look for answers. The Requirements Elicitation Process should focus on the wish-list of this defined group to arrive at a valid requirements list.

III. Requirements elicitation
Information is gathered from the multiple stakeholders identified. The Requirements Analyst draws out from each of these groups what their requirements from the application are and what they expect the application to accomplish.
Considering the multiple stakeholders involved, the list of requirements gathered in this manner could run into pages. The level of detail of the requirements list is based on the number and size of user groups, the degree of complexity of business processes and the size of the application.

a) Problems faced in Requirements Elicitation

• Ambiguous understanding of processes
• Inconsistency within a single process by multiple users
• Insufficient input from stakeholders
• Conflicting stakeholder interests
• Changes in requirements after project has begun

A Requirements Analyst has to interact closely with multiple work-groups, often with conflicting goals, to arrive at a bona fide requirements list. Strong communication and people skills along with sound programming knowledge are prerequisites for an expert Requirements Analyst.

b) Tools used in Requirements Elicitation

Traditional methods of Requirements Elicitation included stakeholder interviews and focus group studies. Other methods like flowcharting of business processes and the use of existing documentation like user manuals, organizational charts, process models and systems or process specifications, on-site analysis, interviews with end-users, market research and competitor analysis were also used extensively in Requirements Elicitation.
However current research in Software Requirements Analysis Process has thrown up modern tools that are better equipped to handle the complex and multilayered process of Requirements Elicitation. Some of the current Requirements Elicitation tools in use are:
• Prototypes
• Use cases
• Data flow diagrams
• Transition process diagrams
• User interfaces

IV. Requirements Analysis Process
Once all stakeholder requirements have been gathered, a structured analysis of these can be done after modeling the requirements. Some of the Software Requirements Analysis techniques used are requirements animation, automated reasoning, knowledge-based critiquing, consistency checking, analogical and case-based reasoning.

V. Requirements Specification
Requirements, once elicited, modeled and analyzed should be documented in clear, unambiguous terms. A written requirements document is critical so that its circulation is possible among all stakeholders including the client, user-groups, the development and testing teams. Current requirements engineering practices reveal that a well-designed, clearly documented Requirements Specification is vital and serves as a:
• Base for validating the stated requirements and resolving stakeholder conflicts, if any
• Contract between the client and development team
• Basis for systems design for the development team
• Bench-mark for project managers for planning project development lifecycle and goals
• Source for formulating test plans for QA and testing teams
• Resource for requirements management and requirements tracing
• Basis for evolving requirements over the project life span

Software requirements specification involves scoping the requirements so that it meets the customer’s vision. It is the result of collaboration between the end-user who is often not a technical expert, and a Technical/Systems Analyst, who is likely to approach the situation in technical terms.

The software requirements specification is a document that lists out stakeholders’ needs and communicates these to the technical community that will design and build the system. The challenge of a well-written requirements specification is to clearly communicate to both these groups and all the sub-groups within.

To overcome this, Requirements Specifications may be documented separately as
• User Requirements - written in clear, precise language with plain text and use cases, for the benefit of the customer and end-user
• System Requirements - expressed as a programming or mathematical model, addressing the Application Development Team and QA and Testing Team.

Requirements Specification serves as a starting point for software, hardware and database design. It describes the function (Functional and Non-Functional specifications) of the system, performance of the system and the operational and user-interface constraints that will govern system development.

VI. Requirements Management
Requirements Management is the comprehensive process that includes all aspects of software requirements analysis and additionally ensures verification, validation and traceability of requirements. Effective requirements management practices guarantee that all system requirements are stated unambiguously, that omissions and errors are corrected and that evolving specifications can be incorporated later in the project lifecycle.

According to THIS website, system requirements can be obtained through the following methods:

Stakeholder identification

Stakeholder are persons or organizations (legal entities such as companies, standards bodies) which have a valid interest in the system. They may be affected by it either directly or indirectly. A major new emphasis in the 1990s was a focus on the identification of stakeholders. It is increasingly recognized that stakeholders are not limited to the organization employing the analyst. Other stakeholders will include:
• anyone who operates the system (normal and maintenance operators)
• anyone who benefits from the system (functional, political, financial and social beneficiaries)
• anyone involved in purchasing or procuring the system. In a mass-market product organization, product management, marketing and sometimes sales act as surrogate consumers (mass-market customers) to guide development of the product
• organizations which regulate aspects of the system (financial, safety, and other regulators)
• people or organizations opposed to the system (negative stakeholders;)
• organizations responsible for systems which interface with the system under design
• those organizations who integrate horizontally with the organization for whom the analyst is designing the system

Stakeholder interviews

Stakeholder interviews are a common technique used in requirement analysis. These interviews may reveal requirements not previously envisaged as being within the scope of the project, and requirements may be contradictory. However, each stakeholder will have an idea of their expectation or will have visualized their requirements.

Contract-style requirement lists

One traditional way of documenting requirements has been contract style requirement lists. In a complex system such requirements lists can run to hundreds of pages.
An appropriate metaphor would be an extremely long shopping list. Such lists are very much out of favour in modern analysis; as they have proved spectacularly unsuccessful at achieving their aims; but they are still seen to this day.

Strengths
• Provides a checklist of requirements.
• Provide a contract between the project sponsor(s) and developers.
• For a large system can provide a high level description.

Weaknesses
• Such lists can run to hundreds of pages. It is virtually impossible to read such documents as a whole and have a coherent understanding of the system.
• Such requirements lists abstract all the requirements and so there is little context
• This abstraction makes it impossible to see how the requirements fit together.
• This abstraction makes it difficult to identify which are the most important requirements.
• This abstraction means that the more people who read such requirements the more different visions of the system you get.
• This abstraction means that it's extremely difficult to be sure that you have the majority of the requirements. Necessarily, these documents speak in generality; but the devil as they say is in the details.
• These lists create a false sense of mutual understanding between the stakeholders and developers.
• These contract style lists give the stakeholders a false sense of security that the developers must achieve certain things. However, due to the nature of these lists, they inevitably miss out crucial requirements which are identified later in the process. Developers can use these discovered requirements to renegotiate the terms and conditions in their favour.
• These requirements lists are no help in system design, since they do not lend themselves to application.

Measurable goals

Best practices take the composed list of requirements merely as clues and repeatedly ask "why?" until the actual business purposes are discovered. Stakeholders and developers can then devise tests to measure what level of each goal has been achieved thus far. Such goals change more slowly than the long list of specific but unmeasured requirements. Once a small set of critical, measured goals has been established, rapid prototyping and short iterative development phases may proceed to deliver actual stakeholder value long before the project is half over.

Prototypes

In the mid-1980s, prototyping was seen as the solution to the requirements analysis problem. Prototypes are Mockups of an application. Mockups allow users to visualize an application that hasn't yet been constructed. Prototypes help users get an idea of what the system will look like, and make it easier for users to make design decisions without waiting for the system to be built. Major improvements in communication between users and developers were often seen with the introduction of prototypes. Early views of applications led to fewer changes later and hence reduced overall costs considerably.

However, over the next decade, while proving a useful technique, prototyping did not solve the requirements problem:
• Managers, once they see a prototype, may have a hard time understanding that the finished design will not be produced for some time.
• Designers often feel compelled to use patched together prototype code in the real system, because they are afraid to 'waste time' starting again.
• Prototypes principally help with design decisions and user interface design. However, they can not tell you what the requirements originally were.
• Designers and end users can focus too much on user interface design and too little on producing a system that serves the business process.
• Prototypes work well for user interfaces, screen layout and screen flow but are not so useful for batch or asynchronous processes which may involve complex database updates and/or calculations.

Prototypes can be flat diagrams (often referred to as Wireframes) or working applications using synthesized functionality. Wireframes are made in a variety of graphic design documents, and often remove all color from the design (i.e. use a greyscale color palette) in instances where the final software is expected to have graphic design applied to it. This helps to prevent confusion over the final visual look and feel of the application.

Use cases

A use case is a technique for documenting the potential requirements of a new system or software change. Each use case provides one or more scenarios that convey how the system should interact with the end user or another system to achieve a specific business goal. Use cases typically avoid technical jargon, preferring instead the language of the end user or domain expert. Use cases are often co-authored by requirements engineers and stakeholders.
Use cases are deceptively simple tools for describing the behavior of software or systems. A use case contains a textual description of all of the ways which the intended users could work with the software or system. Use cases do not describe any internal workings of the system, nor do they explain how that system will be implemented. They simply show the steps that a user follows to perform a task. All the ways that users interact with a system can be described in this manner.

Software requirements specification

A software requirements specification (SRS) is a complete description of the behavior of the system to be developed. It includes a set of use cases that describe all of the interactions that the users will have with the software. Use cases are also known as functional requirements. In addition to use cases, the SRS also contains nonfunctional (or supplementary) requirements. Non-functional requirements are requirements which impose constraints on the design or implementation (such as performance requirements, quality standards, or design constraints).
Recommended approaches for the specification of software requirements are described by IEEE 830-1998. This standard describes possible structures, desirable contents, and qualities of a software requirements specification.

Now, here are my answers…

a. Obviously these two workers have different views on how the systems analysis phase should be conducted. Comment on whose position you sympathize with the most.

From the scenario above, I sympathize more on Peter Pedro for the following reasons:

First, the fact that Pedro’s company has been through projects that have been unsatisfying because of the undelivered requirements makes the method proposed by Juan to be ineffective for them. Although Juan thinks that his methods on requirements analysis is effective, if the customer already testified its unproductiveness based on the previous projects, why do it again?

Second, Pedro clearly specified that they want a NEW system. Therefore, Juan’s team should concentrate on creating a new system instead of concentrating on the old one.

Third, customers should get what they want instead on getting what the system professionals want for them. Juan should understand that they are paid to satisfy the need of their clients and not satisfy what they think is the need of the client.


b. What method would you propose they take? Why?

The first step that both parties should take is to formulate an SRS or Software requirements specification for the system as a requirement analysis method for the development. Since the SRS document contains the complete description of the behavior of the system, it will enable Pedro to list down all the functional and non-functional requirements that they need for the system and the document will also serve as a complete reference guide for Juan and his team.

In terms of development methodology, I think that they should use AGILE methodology because I believe that it is a very flexible and effective methodology for developing systems. But the methodology to be used will still depend on some details and constraints of the development which are not mentioned in the scenario.


Reference:
http://www.outsource2india.com/software/RequirementAnalysis.asp
http://en.wikipedia.org/wiki/Requirements_analysis

Note: This post is a response to SAD 1 assignment # 6