Requirement Analysis

Requirements Engineering (RE) is one of the most critical tasks undertaken by software engineers. It is the process of articulating a set of user requirements that must be met. Requirements are the things that should discovered before even starting to build a software product.

Mohapatra (2000, p.63) cites a 1994 study by The Standish Group which found that “the three most commonly cited root causes of project failures, responsible for more than a third of the projects running into problems, are the following:

• Lack of user input: 13% of all projects.
• Incomplete requirements and specifications: 12% of all projects.
• Changing requirements and specifications: 12% of all projects.

Despite this study being conducted nearly 30 years ago the findings remain relevant now. The functions of a software product must match the user requirements. It should be evident that without a clear set of specific user requirements, a software product cannot (should not) be developed else you might find user needs are not met, and the effort and cost expended on the development of the product will be wasted.

Essentially, Requirement Engineering is the process of defining, documenting, and maintaining the requirements of a software product. It is a process of gathering and defining services provided by the software that are aligned with the needs and wants of various stakeholders. It is the way to ensure the development of high quality software product that meets stakeholder/user expectations.

Requirement Engineering has two important tasks:

1. Establishing the specific requirements and articulating them clearly (these are sometimes referred to as work products), and
2. Reviewing the work products (specifications) with customers/users to ensure their correctness.

There are several steps in the requirements engineering process. The phases of the RE process are considered in some detail in this topic, as it through this process that the above tasks are met. The RE process can look something like the image below, but as you will have encountered throughout this course there are always variations and adaptations to processes, and you will need to acquaint yourself with the specific processes utilized in the company you may find yourself working for/with.

Before we look at this process lets take some time to understand what requirements are in more detail.

Simply put requirements are what ‘people’ want in a software system or product. ‘People’ are the various stakeholders in the development process, including the client (person or organisation who commissions the project) and end-users. They are things that software developers should ascertain before even starting to build a software product or system. It is akin to the User Research phase of the UX Design process which you have been previously introduced to.

These requirements reflect the specific features of user need, and when identified should be expressed in the language of the user. Leffingwell and Widrig, cited in Mohapatra (2000), define these requirements as software capabilities that the user needs to solve a problem, or problems, to achieve their objective, and a set of capabilities that must be met or possessed by the software system in order to satisfy contractual obligations, standards, specifications or other expectation.

“Without a clear specification of a set of valid user requirements, a software product cannot be developed, and the effort expended on the development will be a waste. The functions of a software product must match the user requirements. Many computer-based information systems have failed because of their inability to correctly capture the user requirements. And when a completed software product is modified to incorporate lately understood user requirements, the effort spent, and consequently, the costs are extremely high.” (Mohaptra 2000, p.63)

Leffingwell and Widrig argue that the user/stakeholder needs sit with what they call the ‘problem domain’, and in the ‘solution domain’ lies software requirements. For them the key to identifying software requirements is to first the features of the software. This is identified in the following example:

User Need	A process to reduce the delay to customer orders
Software Features to meet the need	Customers can send an order online Acknowledgements of the receipt of orders is sent on online Status of customer is updated regularly and available online Invoices are sent to customers online
Software Requirements/Specification to meet Feature 1	Selected items are automatically placed in the shopping basket The selected products are listed in the shopping basket with price The shopping basket form is accommodated on a single page Changes to the order (product deletion, increase of item quantity, and addition of new items) is available from the shopping basket Freight fees are automatically calculated Verification of payment of completed order is immediately display, and email confirmation is sent. Order tracking information is sent to customer when the item is shipped.

Sommerville (1999) classifies requirements in two major groups:

1. Enduring requirements, which are the requirements of the users are core and stable, and:
2. Volatile requirements which change during the development of, or operation with the software. These volatile requirements can be categorised in 4 ways:
   1. Mutable requirements, which are likely to change due to changes in environment.
   2. Emergent requirements, which appear as users begin to understand the functionalities of the software as it is developed.
   3. Consequential requirements, which appear when a computer system replaces a manual one.
   4. Compatible requirements, which change when business processes change.

The issue with these volatile requirements is that they are difficult to gauge and incorporate in the software development – they can be like shifting sands. Furthermore, not all these requirements are necessarily conscious (as in the users/stakeholders are aware of them), they can be assumed or unconscious, or not thought possible by the stakeholder and therefore not asked for. (Robertson and Robertson (2000) cited in Mahopatra, 2000).

Defining Requirements

Stephens (2015, pp54-61) asserts that for requirements to be useful they should have the following properties:

Clear

Requirements should not be vague or poorly defined they must be concrete, clear, concise, easy to understand and describes exactly what is required.

Avoid management-speak, confusing jargon or elaborate text. If using technical terms or abbreviations, make sure they are defined somewhere or are common knowledge in the project.

Stephens (p.55) gives this example:

“Suppose you’re working on a program to schedule appointments for utility repair people. (Those appointments that typically say, “We’ll be there sometime between 6:00 a.m. and midnight during the next 2 weeks.”) A requirement such as, “Improve appointment scheduling,” is too vague to be useful. Does this mean you should tighten the appointment windows even if it means missing more appointments? Does it mean repair people should leave and make a new appointment if they can’t finish a job within 1 hour? Or does it mean something crazy like letting customers tell you what times they can actually be home and then fitting appointments to those times?

A better requirement would be, “Reduce appointment start windows to no more than 2 hours while meeting 90 percent of the scheduled appointments.”

Unambiguous

Do your best to write unambiguous requirements. It might sound simple, but it can be harder than what you might think. They need to be written in a way in which you can’t interpret them in any way other than what you intend. It can help to run them past other people to see if they interpret them the same way as you do.

“For example, suppose you’re building a street map application for inline skaters, and you have a requirement that says the program will, “Find the best route from a start location to a destination location.” This can’t be all that hard. After all, Google Maps, Yahoo Maps, MapQuest, Bing Maps, and other sites all do something like this. But how do you define the “best” route? The shortest route? The route that uses only physically separated bike paths so that the user doesn’t have to skate in the street? Or maybe the route that passes the most Starbucks locations?

Even if you decide the “best” route means the shortest one, what does that mean? The route that’s the shortest in distance? Or the shortest in time? What if the route of least distance goes up a steep hill or down a set of stairs and that increases its time? “

Consistent

There must be consistency between requirements, in that not only should they not contradict each other they should not add too many constraints to solving the user’s problem. It helps greatly to keep new requirements consistent with any existing requirements. Alternatively, you may find it better to rewrite older requirements as necessary. However, whatever you decide to it is helpful when you completed the gathering of all the requirements, go through them again and look for inconsistencies. Each requirement must also be self-consistent (i.e. it must be possible to achieve).

Prioritized

At the beginning of a project you will probably have a list of ‘nice-to-have’ features in the design. You might like to include every feature but are constrained by timeframes or budget, so some of those ‘nice-to-have’ features will have to be removed from the project design. This means you will need to prioritize the requirements. Stephens writes “If you’ve assigned costs (usually in terms of time to implement) and priorities to the requirements, then you can defer the high‐cost, low‐priority requirements until a later release.”

Your customers are very likely to have trouble deciding which requirements they can live without, but unless they can come up with a big enough budget and timescale, they will have make some decisions. As a software engineering you can facilitate this to achieve a product that most closely reflects the customer’s dream.

A useful tool to help you with prioritizing requirements is the MoSCoW method. This is an acronym to help you remember a commonly used system for prioritizing requirements. It stands for:

Mo	Must	These are features that are required and must be included in the product. They are necessary, and vital to software working correctly
S	Should	These features are important and should be included if it is possible. If there is no way to include them in the first release, they can be deferred to the second release.
Co	Could	These features are desired, but they can be left out of the development. They could be included in the second release but are less important than the ‘should’ features so can be left out totally.
W	Won't	These are completely optional features that the customer has agreed will not be included in the release, but they may be included in a later iteration if time and budget permits.

Verifiable

Requirements must be verifiable. If you can’t verify a requirement, how do you know whether you’ve met it?

Being verifi able means the requirements must be limited and precisely defi ned. They can’t be open‐ended statements such as, “Process more work orders per hour than are currently being processed.” How many work orders is “more?” Technically, processing one more work order per hour is “more,” but that probably won’t satisfy your customer. What about 100? Or 1,000? A better requirement would say, “Process at least 100 work orders per hour.” It should be relatively easy to determine whether your program meets this requirement.

Even with this improved requirement, verifi cation might be tricky because it relies on some assumptions that it doesn’t defi ne. For example, the requirement probably assumes you’re processing work orders in the middle of a typical workday, not during a big clearance event, during peak ordering hours, or during a power outage.

An even better requirement might be, “Process at least 100 work orders per hour on average during a typical work day.” You may want to refine the requirement a bit to try to say what a “typical work day” is, but this version should be good enough for most reasonable customers.

The categories of requirements vary depending on the framework being presented. In this section you will be introduced to a number of categories. You will note as you increase your understanding of Requirements Engineering that different writers’ categorize requirements in different ways, but if you look at them closely you will find that all requirements can be placed in any of the category types.

Thakur classifies requirements into three categories as seen in the diagram below:

Functional Requirements are the statements of services the system should provide, how the system should react to the different kinds of inputs and how the system should behave in particular situations. These requirements

• Describe functionality or system services.
• Depend on the type of software, expected users and the type of system where the software is used.
• Functional user requirements may be high-level statements of what the system should do.
• Functional system requirements should describe the system services in detail.

We can see that functional requirements are detailed statements of the project’s desired capabilities. These are things the application should do. They are similar to user requirements, but they also include things that the users won’t see directly. For example, they might describe reports that the application produces, interfaces to other applications, and workflows that route orders from one user to another during processing.

Note that some requirements could fall into multiple categories. For example, you could consider most user requirements to be functional requirements. They not only describe a task that will be performed by the user, but they also describe something that the application will do.

Non-functional Requirements are statements about the quality of the application’s behaviour or the constraints on the services or functions offered by the system . Examples of the requirements include timing constraints, constraints on the development process, standards and other factors that are not directly related to the operation of the software system itself. They often apply to the system as a whole rather individual features or services.

Non-functional requirements

• define system properties and constraints e.g. reliability, response time and storage requirements. Constraints are I/O device capability, system representations for example.
• Process requirements may also be specified mandating a particular IDE, programming language or development method.

Non-functional requirements may be more critical than functional requirements. If these are not met, the system may be useless. The types of non-functional requirements are identified below:

Product Requirements

These are the requirements which specify that the delivered product must behave in a particular way e.g. execution speed, reliability, etc. They include

• Usability Requirements
• Efficiency Requirements
  • Performance Requirements
  • Space Requirements
• Dependability Requirements
• Security Requirements

Organisational Requirements

These requirements are a consequence of organisational policies and procedures e.g. process standards used, implementation requirements, and include

• Environmental Requirements
• Operational Requirements
• Development Requirements

External Requirements

External requirements arise from factors which are external to the system and its development process e.g. interoperability requirements, legislative requirements, and include the following sub categories

• Regulatory Requirements
• Ethical Requirements
• Legislative Requirements
  • Accounting Requirements
  • Safety/Security Requirements

Non-functional requirements may affect the overall architecture of a system rather than the individual components. For example, to ensure that performance requirements are met, you may have to organize the system to minimize communications between components.

A single non-functional requirement, such as a security requirement, may generate a number of related functional requirements that define system services that are required. It may also generate requirements that restrict existing requirements.

Domain Requirements are constraints on the system in operation domain.

Examples of non-functional include:

• Response time and net processing time
• Capacity, growth and scalability
• Service levels and SLAs(Server Level Agreements)
• Maintainability
• Security
• System management
• Legal/regulatory
• Application architecture
• Data architecture
• Technology architecture
• Network architecture
• Organisational design and change management
• Training, target audience and communications
• Ongoing support and maintenance requirements
• Usuability objectives
• Locations/physical environment
• Delivery, deployment and timing requirements
• Development standards

Let’s look at the following example to illustrate the functional and non-functional requirements.

You are developing a Patient Information Management System (PIMS) that will maintain information about patient ailments and conditions, and their treatment. The PIMS should enable clinicians to add medical information, care management plans, monitor patient progress, provide monthly admin reporting, information about medicines prescribed, maintain patient privacy, and so on.

The PIMS has two purposes:

1. To generate management information that allows health service managers to assess performance against local and government targets.
2. To provide medical staff with timely information to support the treatment of patients.

The key features of the system are:

• Individual care management
• Patient monitoring
• Administrative reporting

Now let’s consider some examples of the software requirement of this system:

Functional Requirements

• A user shall be able to search the appointments lists for all clinics.
• The system shall generate each day, for each clinic, a list of patients who are expected to attend appointments that day.
• Each staff member using the system shall be uniquely identified by his or her 8-digit employee number.

Non-functional Requirements

• Product requirement - The PIMS shall be available to all clinics during normal working hours (Mon–Fri, 0830–17.30). Downtime within normal working hours shall not exceed five seconds in any one day.
• Organizational requirement - Users of the PIMS shall authenticate themselves using their health authority identity card.
• External requirement - The system shall adhere to patient privacy provisions as set out in NZ Health Information Privacy Code

The blog by Software Testing Help (June 13, 2022) entitled “Features of Functional Requirements and Non-Functional Requirements” provides a handy overview of these requirements.

In the following video Brigit Penzenstadler discusses another way of looking at non-functional requirements. Take note of her comments about dealing with the variations and ideas regarding requirements and how you might deal with the differences.

You are also able to access her powerpoint on Slideshare.

Two alternative ways of categorizing requirements are given below.

Stephens (2015)	Mishra & Mohanty (2011) citing IEEE Standard 610.12-1990
Audience-oriented Requirements: Business Requirements User Requirements	Design Requirements Functional Requirements Implementation Requirements Interface Requirements Performance Requirements Physical Requirements

In this section of the topic, we will take some time to explore the Requirements Engineering process. A diagram was presented right at start and included some preliminary steps – the feasibility study.

The feasibility study is used to establish whether the proposed system or software product can be built with the current technologies available and the proposed budget. It is usually a quick process with outcome being used to determine whether the project should proceed or not. For arguments sake we have undertaken the feasibility study and it has been agree the product will be developed.

In this section we will explore the steps outlined in the diagram below:

Requirements Elicitation

Sometimes this stage is called ‘requirements gathering’, it is part of the process where you research and discover the requirements of a system from the various stakeholders. It is the process of deriving the system requirements through a number of techniques that are used to elicit the requirements from stakeholders

Mishra and Mohanty (2011) states that the “following information can be sought from the customers and the users:

• What are the objectives of the software product?
• What is to be accomplished by the software?
• How does the software fit into the needs of the business?
• How is the software to be used on a day-to-day basis?

The stages of the elicitation process include:

• Requirements discovery,
• Requirements classification and organization,
• Requirements prioritization and negotiation,
• Requirements specification

Geeksforgeeks (13 Jul 2022) highlight the following challenges you might face in the elicitation phase:

• Understanding large and complex system requirements is difficult
• Undefined system boundaries
• Customers/Stakeholders are not clear about their needs
• Conflicting requirements are present
• Changing requirements
• Partitioning the system suitably to reduce complexity
• Validating and Tracing requirements
• Identifying critical requirements
• Resolving the “to be determined” part of the requirements
• Proper documentation, proper meeting time, and budget constraints

These challenges are described in detail here.

A number of different techniques are used to elicited requirements. You will be familiar with some of them from the UX design research process. Both quantitative and qualitative information is required to clearly determine the requirements therefore the following techniques reflect that:

1. Interviews
2. Brainstorming Sessions
3. Surveys/Questionnaires
4. Facilitated Application Specification Technique (FAST)
5. Quality Function Deployment (QFD)
6. Use Case Approach

Interviews

One-on-one interviews are among the most popular types of requirements elicitation. They give the software engineer the opportunity to discuss in-depth a stakeholder’s thoughts and get their perspective on the business need and the feasibility of potential solutions.

Interviews maybe be open-ended or structured. In open-ended interviews there is no pre-set agenda. Context free questions may be asked to understand the problem. In structured interviews, an agenda is set using fairly open questions. Sometimes a more formal questionnaire is designed for the interview, and specific targeted questions are asked. Whether you choose to have a structured (with predefined questions) or unstructured interview (with free-flowing, back-and-forth conversation), you must fully understand the business need in order to conduct a successful interview. It is a good practice to share the interview notes with the interviewee afterward to ensure there were no misunderstandings and to jog the interviewee’s thoughts for any further insights.

When interviewing it is good practice to be open-minded, avoid pre-conceived ideas about the requirements and be willing to listen to stakeholders. You can prompt the interviewee to get discussions going using a springboard question, a requirements proposal, or by working together on a prototype system.

Brainstorming Sessions

The purpose of gathering your stakeholders for brainstorming is to produce numerous new ideas, and to derive from them themes for further analysis. You should try to secure a representative from each participating stakeholder group in the brainstorming session. When facilitating a brainstorming session, it is important to ensure that while participants feel free to propose new ideas and solutions, they remain focused on the business need at hand and do not engage in what we call scope creep, gold plating, or become distracted with other business issues.

All ideas in the session must be recorded so that they are not lost for later analysis.

Given brainstorming is a group technique you will need to develop skill in handling group bias and conflict within the group

Surveys/Questionnaires

Surveys are useful for quickly gathering data from a large group of participants. Because free online survey software is readily available, surveys are an inexpensive way to gather objective input from customers or potential end users. As with selecting stakeholders, a successful survey or questionnaire must have well-chosen participants.

Surveys can be structured to offer a series of finite choices for feedback, or they can offer open-ended input, depending on the needs of the project at hand. Open-ended surveys are useful for a broader discovery of business needs; however, the larger the number of participants in open-ended surveys, the more prohibitive they are to analyze.

Survey wording must be unambiguous and precise. It is good practice to politely request that survey participants respond by a reasonable deadline and that they keep any proprietary business information contained within the survey confidential.

Facilitated Application Specification Technique (FAST)

The Facilitated Application Specification Technique is a team-oriented approach that is practiced during the early stages of analysis and specification to facilitate proper discussions. FAST helps in creating a joint team between developers and customers that helps them to work together by understanding the expectations and purpose of the requirements.

In this method each attendee is asked to make a list of objects/needs that are-

• Part of the environment that surrounds the system
• Produced by the system
• Used by the system

Each participant prepares his/her list, then different lists are then combined, and redundant/duplicate entries are eliminated. The team is divided into smaller sub-teams to develop mini-specifications and finally a draft of specifications is written down using all the inputs from the meeting.

The following guidelines help to support this process:

• To control the meeting, there is a need for having a facilitator
• This meeting is conducted at a neutral site where the software engineering analysts and customers are comfortable to meet
• There are certain rules to prepare and participate in the meeting and these should be established before the start of a meeting
• An agenda is suggested for both the teams so that they will be enough scope for discussing all important points

Quality Function Deployment (QFD)

Quality Function Deployment (QFD) is a process and set of tools used to effectively define customer requirements and convert them into detailed engineering specifications and plans to produce the products that fulfil those requirements. QFD is used to translate customer requirements into measurable design targets. QFD methodology provides a defined set of matrices utilized to facilitate this progression.

There are several benefits to using Quality Function Deployment:

1. Customer Focused: The QFD methodology places the emphasis on the wants and needs of the customer, not on what the company may believe the customer wants. The customer wants/needs are translated into technical design specifications. During the QFD process, design specifications are driven down from machine level to system, sub-system and component level requirements. Finally, the design specifications are controlled throughout the production of the product to assure the customer needs are met.
2. Competitor Analysis: The QFD “House of Quality” tool allows for direct comparison of how your design or product compares with competitors in meeting the requirements.
3. Shorter Development Time and Lower Cost: QFD reduces the likelihood of late design changes by focusing on product features and improvements based on customer requirements. Effective QFD methodology prevents valuable project time and resources from being wasted on development of non-value-added features or functions.
4. Structure and Documentation: QFD provides a structured method and tools for recording decisions made and lessons learned during the product development process. This knowledge base can serve as a historical record that can be utilized to aid future projects.

Customer satisfaction is the prime concern; hence it emphasizes the valuable requirements to the customer.

Three types of requirements are identified:

• Normal requirements – These cover the objective and goals of the proposed software are discussed with the customer. For example – normal requirements for a result management system may be the entry of marks, calculation of results, etc.
• Expected requirements – These requirements are so apparent that the customer need not explicitly state them: for example – protection from unauthorized access.
• Exciting requirements – These requirements include features beyond customers' expectations yet they satisfy the customer when they are present. For example – when unauthorized access is detected, it should back up and shut down all processes.

The steps involved in this process are:

1. Identify all the stakeholders, e.g., Users, developers, customers, etc
2. List out all requirements from the customer.
3. The degree of importance is given to every requirement.
4. In the end, the final list of requirements is divided up into the following categories:
   1. It is possible to attain.
   2. It should be deferred, and the reason for it.
   3. It is not possible to achieve and should be dropped off.

Use Case Approach

In this technique, text and pictures are combined to understand the requirements better. The use cases describe the 'what' of a system and not 'how .' Therefore, they only give a functional view of the system.

The components of the use case design include three major things – Actor, Use cases, Use case diagram.

Actor – This is an external agent that lies outside the system but interacts with it somehow. An actor, maybe a person, a machine, or something else. It is shown as a stick figure. Actors may be primary actors or secondary actors.

• Primary actors – They require assistance from the system to accomplish a goal.
• Secondary actor – The system demands assistance from secondary actors.

Use Cases –These cases describe the sequence of interactions between the system and actors. They capture who(actors) do what(interaction) with the system. A set of Use cases specifies all possible ways to use the system.

Use case diagram – A use case diagram represents what happens when an actor graphically interacts with a system. It has the functional side of the system. The legend for diagram is as follows:

• A Stick figure is used to show an actor.
• An Oval is used to show the use case.
• A line represents a relationship between an actor and a use case.

Take a look at this quirky little video about Use Case Design.

In this short video Birgit Penzenstadler provides a succinct overview of the elicitation techniques that you will use to ascertain the requirements.

Requirements Analysis

Having completed the elicitation phase, you move on to Requirements Analysis (RA). In this phase you take the Information gathered during the elicitation phase and analyse them. The aim of the analysis phase to come up with a set of consistent and unambiguous requirements. This means subjecting the data gathered to scrutiny, in order to refine the information.

The Institute of Electrical and Electronics Engineers (IEEE) identifies two aspects of RA:

1. It is the process of studying user needs to arrive at a definition of a system, hardware or software requirements, and
2. The process of studying and refining system, hardware or software requirements

Requirements analysis helps to understand, interpret, classify, and organize the software requirements in order to assess the feasibility, completeness, and consistency of the requirements. Various other tasks performed using requirements analysis are listed below:

• To detect and resolve conflicts that arise due to unclear and unspecified requirements
• To determine operational characteristics of the software and how they interact with the environment
• To understand the problem for which the software is to be developed
• To develop an analysis model to analyze the requirements in the software.

Javatpoint (n.d.) propose a 4-step process of analysis. The process is shown in the image below:

Let’s elaborate each step of the process as described by Javatpoint.

Draw the Context Diagram

The context diagram is a simple model that defines the boundaries and interfaces of the proposed systems with the external world. It identifies the entities outside the proposed system that interact with the system. Javatpoint use the example of a Student Result Management system to illustrate this map:

Development of a Prototype

This stage is optional, but the construction of a prototype can be an effective way to find out what the customer wants. It provides them with something that looks and preferably acts as part of the system they say they want.

User feedback is then used to modify the prototype until they are satisfied. The length of time to complete this step is dependent on factors like budgets and deadlines. To help refine the prototype you can make use of prioritisation system like the one that was presented earlier in this topic.

The prototype helps the client to visualize the proposed system and increase the understanding of the requirements. Where developers and users are not sure about some of the elements, a prototype may help decision making.

Where a project is being developed for the general market release you should present the prototype to a representative sample of the user population.

The prototype should be built quickly and at a relatively low cost. It is important to realise that with any prototype there will always be limited functionality.

Model the Requirements

In this phase of the process, you will create various graphical representations of the functions, data entities, external entities, and the relationships between them. These graphical views may help you to find incorrect, inconsistent, missing, or superfluous requirements. There are a variety of graphical models including Data Flow diagrams, Entity-Relationship diagram, Data Dictionaries, and State-transition diagrams.

In the videos below each of these graphical models are described

Data Flow Diagrams (DFD)

Entity-Relationships Diagrams

Data Dictionaries

State-Transition Diagrams

Finalise the Requirements

In this last phase of the Requirements Analysis process, you have established a set of consistent and unambiguous requirements and need to start developing the Requirements Specifications document.

Requirements Specification

This phase involves the writing down the user and system requirements in a requirements document.

User requirements must be understandable by end-users and customers who do not have a technical background. The system requirements are more detailed requirements and may include more technical information. Also remember that the requirements may be part of a contract for the system development which has been raised previously.

It is important that the Requirements Specification Document (also called the Software Requirements Specification SRS) is as complete as possible.

The SRS is the official statement of the system requirements. This is how the system developers and software engineers know what is required. The document should include both a definition of user requirements and a specification of the system requirements.

Note that it is NOT a design document, rather it is the document that sets out WHAT the system should do rather than HOW it should do it.

There will be a number of different stakeholders to read the document, so it must be as technical as possible, but not so full of jargon that those without software development knowledge and skills will be able to read the document and understand the requirements. The following stakeholders may read the SRS:

System users	They will read the SRS with a view to understand the requirements and check that they align with their needs and wants.
Managers	They will be looking to use the SRS as supporting documentation as they plan the system development process and timeline
System engineers	The document will be used to understand what is required in the system and form the base of their plan to build the system
System test engineers	The document will guide them as they develop the various tests and processes they will use to test the system
System maintenance engineers	The requirements are used to understand the system and the relationship between the aspects and parts of the system

You will find that there are various templates that will used to development the Software Requirements Specification. As has been emphasized at various times in the course you will be ultimately guided by the specific processes and templates used by your employing organisation. In saying that you will find that following sections will form the core of the SRS:

Section or Chapter Focus	Description of Section Content
System requirements specifications	In this section the functional and non-functional requirements are described in detail. Interfaces with other systems may also be defined in this section
System Models	In this section you will find the graphical models that show the relationships between system components, the system operation and its environment. Object models, dataflow diagrams or semantic data models may be included in this section
System Evolution	In this section you will find descriptions of the fundamental assumptions on which system is based, along with any anticipated changes that may arise as a result of hardware evolution, changing user needs, and other dynamic factors. This section is useful for system designers as it may help them avoid design decisions that would constrain likely future changes to the system
Appendices	The appendices should provide detailed, specific information that is related to the application being developed; for example, hardware and database descriptions. Hardware requirements define the minimal and optimal configurations for the system. Database requirements define the logical organization of the data used by the system and the relationships between data.
Index	Several indexes to the document may be included. As well as a normal alphabetic index, there may be an index of diagrams, or an index of functions for example

Requirements Validation

This phase is the process of checking that requirements defined for development, actually define the system that the customer really wants. Requirements validation is used check issues related to requirements

Different test may be used to check the requirements mentioned in the Software Requirements Specification (SRS), and can include:

• Completeness checks
• Consistency checks
• Validity checks
• Realism checks
• Ambiguity checks
• Verifiability

The outcome of requirements validation may be a list of identified problems and the agreed upon actions to resolve the identified issues. There are several techniques which are used either individually or in conjunction with other techniques to check to check entire or part of the system.

Test case generation

The requirement outlined in SRS document should be testable. Tests are developed and conducted to reveal any errors present in the requirements. It is generally believed that if the test is difficult to design then it usually means that specific requirement will be difficult to implement, and it should be reconsidered or revised.

Prototyping

In this validation technique the prototype of the system is again presented before the end-user or customer. They experiment with the presented model and check if it meets their need. This type of model is generally used to collect feedback about the requirement of the user.

Requirements Reviews

In this approach, the SRS is carefully reviewed by a group of people that includes people from both the contractor organisations and the client side. In the review the group systematically analyses the document to check error and ambiguity.

Automated Consistency Analysis

This approach is used for automatic detection of an error, such as nondeterminism, missing cases, a type error, and circular definitions, in requirements specifications. First, the requirement is structured in formal notation then a CASE tool is used to check for any inconsistencies in the system. The inconsistencies are identified and a plan for corrective actions is developed.

In this topic you have explored the processes for establishing the requirements for developing a software system. As you develop your practice as a software engineer you will find variations in the application of these process, but regardless of the way in which requirements are gathered, analysed, and documented it should be clear that without establish clear and unambiguous requirements any project is a risk of failure or needless cost over-runs.