Many projects fail because many start to implement a system without determining if what is being implemented is what the customer really wants, then the buy in from key stake-holders is missing and because the buy in from the end users is missing.  So it is important to learn and understand the nuances of requirements analysis and specification techniques thoroughly for system design and development, to address these key issues. The term Requirement is not used in the software providing industry and within the software consuming industry in a uniform manner.  It may range from a high-level abstract statement of a service that system should provide to a detailed formal definition of a system function and how it should be performed. This is inevitable as requirements may serve a dual function. It may be the basis for a bid for a contract – therefore must be open to interpretation, it may be the deliverable for the contract itself – therefore must be defined in detail and also surprisingly both these documents may be called requirements.

According to Davis, “If a company wishes to let a contract for a large software development project, it must define its needs in a sufficiently abstract way that a solution is not pre-defined. The requirements must be written so that several contractors can bid for the contract, offering, perhaps, different ways of meeting the client organisation’s needs. Once a contract has been awarded, the contractor must write a system definition for the client in more detail so that the client understands and can validate what the software will do. Both of these documents may be called the requirements document for the system.”

In more generic terminologies, Requirement Analysis in an information systems development context, encompasses those tasks and activities that go into determining the needs or conditions to meet for a new or altered information systems solution or product, taking account of the possibly conflicting requirements of the different stakeholders while analyzing, documenting, validating and managing the  information systems’ requirements, throughout the life-cycle of this complicated process. It is always prudent to start off requirement analysis with a feasibility study.  The feasibility study decides whether the proposed system development is worthwhile. It is a short focused study that checks if the system contributes to organizational objectives, if the system can be designed using current technology expertise & within budget, if the system can be integrated with other systems that are in existence and if the system can be developed within the desired time-line by the specific team.  Based on information assessment, information collection and report writing through specific questions.

1. What if the information system wasn’t implemented? How would it be different?
2. What are current systemic and non-systemic problems within existing processes? How will the proposed system development help in addressing these?
3. What will be the integration challenges with the existing information systems? How can they be addressed and the risks be mitigated?
4. Is a new information system at all needed? What skills would be needed among the different stakeholders to use it effectively? Is that feasible among the existing human resources?
5. What timeline of system delivery is desired for the solution? Is it feasible?
6. What facilities and infrastructure must be supported by the proposed information system?

The Goals of requirements analysis and specification phase is to  fully understand the user requirements, remove inconsistencies, incompleteness and anomalies from requirements and document requirements properly in an Software Requirement Specification (SRS) document. The SRS document forms the basis for future reference in an information systems project.

Then in the next stage, Elicitation and Analysis is conducted to understand the requirements properly in greater details. This is sometimes called requirements elicitation or requirements discovery. It involves technical staff working with customers to find out about the application domain, the services that the system should provide and the system’s operational constraints.  It may involve end-users, managers, engineers involved in maintenance, domain experts, trade unions, etc. These are called stakeholders. Multi-Stakeholder Viewpoints are important, since  viewpoints are a way of structuring the requirements to represent the perspectives of different stakeholders. Stakeholders may be classified under different viewpoints. This multi-perspective analysis is important as there is no single correct way to analyse system requirements. Such stake-holders could be

• Interactor viewpoints: People or other systems that interact directly with the system. For example, in a banking facility, the service providers and the account database administrator are interactor viewpoints.
• Indirect viewpoints: Stakeholders who do not use the system themselves but who influence the requirements. In a banking facility, the branch manager and security staff could be indirect viewpoints, since they have an overview of the effectiveness of the utilization of the existing systems and their limitations. Further a holistic view of the processes may be captured.
• Domain viewpoints: Domain characteristics and constraints that influence the requirements. In a banking facility, an example would be standards for inter-bank communications support.

It is important to Identify viewpoints using Providers and receivers of system services; Systems that interact directly with the system being specified; Regulations and standards; Sources of business and non-functional requirements, Engineers who have to develop and maintain the system; and Marketing and other business viewpoints. After the requirements are being elicited, they  may be classified into two categories based on Usage Specificity.

• User requirements: which are the high level of system requirements. These are statements in natural language plus diagrams, of what services the system is expected to provide and the constraints under which it must operate. It comes from a user and expresses a property of the domain or business process that the introduction of a new system will bring about.
• System requirements: which are the detailed description of what the system should do. It is a structured document setting out detailed descriptions of the system’s functions, services and operational constraints. It defines what is to be implemented. It may be part of a contract between client and contractor. It expresses a desirable system property that, when implemented in the business process, will lead to the achievement of at least one user requirement.

Further requirements may be classified based on Objective Specificity. Object Specificity defines the traceability of requirements to functional needs of the system and operational needs of the system being designed and developed.

• Functional requirements: These are statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations. These describe functionality or systems’ services. These depend on the type of software, expected users and the type of system where the software is used. Also functional user requirements may be high-level statements of what the system should do but could also describe the system services in detail. Basically these functional requirements attempt to describe a set of high-level requirements where each high-level requirement takes in some data from the user & outputs some data to the user, each high-level requirement might consist of a set of identifiable functions, and every function is described in terms of input data set, output data set, & processing required to obtain the output from the input

• Non-functional requirements: These are constraints on the services or functions offered by the system such as time constraints, constraints on the development process, standards, etc. These are the core characteristics of the system which can not be expressed as functions: like Maintainability (e.g. Planned and unplanned, complexity); Portability (e.g. Interface with other external systems), Usability: human-computer interface issues, Reliability issues: Dependability on outcome (e.g. Accurate billing for a TPS), Performance issues (e.g. System availability) and security, maintainability, etc.Non-functional requirements may be more critical than functional requirements since if these are not met, the information system is likely to be completely useless even if it meets the functional requirements correctly.

• Domain requirements: These are requirements that come from the application domain of the system and that reflect characteristics of that domain. Derived from the application domain and describe system characteristics and features that reflect the domain.Domain requirements be new functional requirements, constraints on existing requirements or define specific computations.If domain requirements are not satisfied, the system may be unworkable or non-functional. Constraints describe things that the system should or should not do. E.G. Standards compliance (Hardware, OS, DBMS, capabilities of I/O devices). How fast the system can produce results so that it does not overload another system to which it supplies data, etc.

Writing Requirements It is of utmost importance that the requirements documented be readable and understandable to the common users of the system. Therefor use natural language and avoid the use of computer jargon. Use language in a consistent way. Use shall/will for mandatory requirements, may/might/could for desirable requirements. Use text highlighting to identify key parts of the requirement. Problems with Natural Language (NL) specification are as follows

1. Ambiguity: The readers and writers of the requirement must interpret the same words in the same way. Natural Language is naturally ambiguous so this is difficult.
2. Over-flexibility: The same thing may be said in a number of different ways in the specification and comprehension would depend on the individual reading the requirements.
3. Lack of modularisation: Natural Language structures are inadequate to structure system requirements for work segregation and module segregation. This creates challenges of allocation and tracking during project execution.

Requirements Discovery: The process of gathering information about the proposed and existing systems and distilling the user and system requirements from this information. Sources of information include documentation, system stakeholders and the specifications of similar systems.  This is basically the process of gathering information through Observation of existing systems, Studying existing procedures, Interviewing key stake-holders, users of the system and through Ethnography (spend time within the system). Requirements Validation: To validate requirements, regular reviews should be held while the requirements are being formulated. During the reviews the following issues are investigated for each requirement:

1. Verifiability. Is the requirement realistically testable? Is the specified requirement objective enough to be tested and established the completion?
2. Comprehensibility. Is the requirement properly understood? Is it complete and adequately understandable?
3. Traceability. Is the origin of the requirement (person or team) clearly identified? (Source, Requirement and design traceability for each requirement through the requirement traceability matrix)
4. Adaptability. Can the requirements be changed without a large impact on other parts of the system development? Till what extent can such changes be accommodated in the existing design planning?
5. Validity: Do the functions, which best support the needs, documented in the proper manner to do what it is supposed to do?
6. Consistency: Are there any requirements conflicts? Are there requirements which conflict in processing the inputs to each other for the same input context?
7. Completeness: Are all functions required by the customer included?
8. Realism: Can these be implemented given the resources

Requirements classification: Subsequently the requirements are classified based on the potential stage when they may emerge for the system developers. Some requirements emerge once the system design is initiated. These requirements may be Mutable, Emergent, Consequential or Compatibility specific requirements.

Requirements documentation: This is the final stage for preparing the SRS document. The requirements are documented from the process stages. It includes all the perspectives from Usage specificity and Objective specificity during discovery and analysis. It addresses requirements validation and classification and also addresses writing requirements standards.  Requirements are approved jointly by specific stake-holders.  High level requirements are signed off by key stake holders (process/function owners).  Low level requirements may be signed off by system users.  The final SRS document is signed off by the Project Manager AND Project Owner (Client Side).

This structure elaborates various components that an SRS document is supposed to capture. This facilitates a structured way of recording the requirements so that the specific perspectives and components mentioned in details, can be captured and elaborated with greater details and planning.

It is important to note that the SRS document is sometimes also referred to as the BRD (Business Requirements Definition) document. It helps in focusing more on the functional requirements and the user requirements, as compared to the SRS Document, which would also look into the system requirements in greater detail. Thus the two documents, although have a similar objective, have a difference in scope.

• Research