read.pudn.comread.pudn.com/downloads208/doc/978592/01 requirements.doc · web viewstudy material....

IQ – INTEGRATED REQUIREMENTS

STUDY MATERIAL

of 34

Date Version Comments

Table of Contents1 SOFTWARE REQUIREMENTS FUNDAMENTALS.......................................................................4

1.1 DEFINITION OF SOFTWARE REQUIREMENTS.....................................................................................41.2 CATEGORIES OF SOFTWARE REQUIREMENTS....................................................................................41.3 REQUIREMENTS PROCESS..................................................................................................................5

2 REQUIREMENTS ELICITATION.....................................................................................................6

2.1 OVERVIEW........................................................................................................................................62.2 THE PROCESS OF REQUIREMENTS ELICITATION...............................................................................6

2.2.1 Project Domain Comprehension..............................................................................................62.2.2 Stakeholder Identification........................................................................................................62.2.3 Stakeholders Analysis...............................................................................................................72.2.4 Selecting the Techniques and Tools.........................................................................................72.2.5 Eliciting Requirements.............................................................................................................92.2.6 Methodology based Requirements Elicitation........................................................................112.2.7 Tools Support for Requirements Elicitation...........................................................................11

3 REQUIREMENTS ANALYSIS..........................................................................................................14

3.1 BASIC GUIDELINES FOR REQUIREMENTS ANALYSIS.......................................................................143.1.1 Establish System Requirements boundary..............................................................................143.1.2 Cross-check with a generic Checklist for requirements analysis...........................................153.1.3 Figure out Overlaps and Conflicts and Resolve them............................................................163.1.4 Plan for conflict resolution.....................................................................................................173.1.5 Assess requirements risk.........................................................................................................17

4 REQUIREMENTS SPECIFICATION..............................................................................................18

4.1 SOFTWARE REQUIREMENTS SPECIFICATION...................................................................................184.2 CONTENTS OF SOFTWARE REQUIREMENTS SPECIFICATION (SRS).................................................184.3 QUESTIONS AN SRS SHOULD ADDRESS..........................................................................................184.4 NOTATIONS VS METHODS/APPROACHES........................................................................................204.5 TOOLS.............................................................................................................................................21

4.5.1 Tool Selection Checklist.........................................................................................................214.6 DOS AND DON’TS............................................................................................................................22

5 REQUIREMENTS VALIDATION....................................................................................................24

5.1 COMPLETENESS OF SRS AS PER TEMPLATE....................................................................................245.2 REQUIREMENTS REVIEWS...............................................................................................................245.3 PROTOTYPING.................................................................................................................................24

of 34

5.4 MODEL VALIDATION.......................................................................................................................245.5 ACCEPTANCE TESTS........................................................................................................................25

6 REQUIREMENTS MANAGEMENT................................................................................................26

6.1 OVERVIEW......................................................................................................................................266.1.1 Traceability.............................................................................................................................26

6.2 CHANGE MANAGEMENT.................................................................................................................276.3 TOOLS.............................................................................................................................................27

7 QUALITY OF REQUIREMENTS.....................................................................................................28

7.1 APPROACHES TO MAINTAIN QUALITY IN REQUIREMENTS..............................................................287.1.1 Constructive Approach...........................................................................................................287.1.2 Analytical Approach...............................................................................................................29

8 REFERENCES.....................................................................................................................................31

of 34

1 Software Requirements Fundamentals“The rate of change in business offerings due to competition is highest at any given point of time”, this statement can remain unchallenged of course at any given point of time but what affects the software industry is that every industry is getting more and more software dependent which implies that the software solution has to cope with this change and thus arises a dire need to document and manage the requirements.

Requirements are statements of what a system must do rather than how it should be done. This is the toughest part of requirements as the requirements engineers are closer to system implementation rather than business domain. It would also be impractical to simply specify requirements without considering implementation concerns thus it is this magical balance that is desired to be obtained and following a disciplinary approach would get us there. This practice area is known as Requirements Engineering.

Requirements Engineering is concerned with systematic Elicitation, Analysis, Specification, Validation and Management of these software requirements.

This material aims at presenting the practices, frameworks, principles, methodologies, tools and related aspects of requirements engineering such that the “Requirements Engineer” is well equipped in the requirements domain.

1.1 Definition of Software RequirementsSimply put, “The needs and constraints placed on a software solution are known as software requirements” and

IEEE 610-12-1990 defines a requirement as:

A condition or capability needed by a user to solve a problem or achieve an objective

A condition or capability that must be met or possessed by a system or a system component to satisfy a contract, standard, specification or other formally imposed documents.

A documented representation of a condition or capability as described above.

This implies that Software requirements are not merely user requirements; they are also requirements from all other stakeholders (Industry, Legal, Organization etc).

Requirements are to say “What” a software solution should do rather than “How”, it is to be done, this is easier said than done but following a suitable approach and keeping a safe distance from implementation helps in doing so.

1.2 Categories of Software Requirements

Requirements can be categorized in many ways, here are some of them:

Functional Requirements : What the system has to do

Non-Functional Requirements: Constraints on the solution, eg. Accuracy, Performance, Security etc

Goal Level Requirements: eg. The operational efficiency of process A will be improved by 40%.

of 34

Domain Level Requirements: eg. A Savings account should be opened in less than 10 mins

Product Level Requirements: eg. The product shall have a export to MS Excel feature

Design Level Requirements: These are to be avoided in the SRS.

Primary Requirements: The requirements elicited directly from the stakeholders.

Derived Requirements: Requirements derived out of primary requirements.

Documentation Requirements: eg. The SRS should be delivered in .PDF format

1.3 Requirements ProcessRequirements Process has five basic activities. These can follow either the iterative model or the spiral model as depicted below. Each of these processes is explained in detailed in the following sections:

of 34

2 Requirements Elicitation

2.1 OverviewSoftware Requirements Elicitation is the process of seeking, discovering, acquiring and elaborating requirements for a computer based system.

The activity of requirements elicitation is all about learning and understanding the needs of the users of the system with the prime aim of communicating these to the system developers. Communication of these “gathered” requirements is explained in detail in Section X, Requirements Specifications. This section aims at explaining the foremost step of the very first stage of SDLC.

2.2 The Process of Requirements ElicitationThe process of Requirements Elicitation is highly communication centric and iterative. Requirements are obtained through communication (From stakeholder to Business Analyst and vice versa) and they undergo refinement, clarification and prioritization; thus the process of requirements elicitation itself needs to be conducive for letting requirements emerge, be discovered and the requirements to be invented. Needless to say, situations get uncontrollable and go out of context if one were to follow these principles as an art form. The following activities can help to bring in discipline and reduce the “artistic” freedom in this process:

2.2.1 Project Domain ComprehensionIt is more than imperative for the Business Analyst (BA) to understand the real world situation and scenarios of the project. Software solutions are meant to no doubt solve a business problem and this problem exists in the real world making it worthwhile to study the problem and the problem area before attempting to solve it.

All domains/businesses have their own terminology and the participants in the requirements process speak the business language, thus making it worth the effort for the BA to understand the right meaning. Additionally the BA may have to understand the political, social and organization constraints.

Artifacts/References: Industry Models, Existing client documentation, Domain Certification, Internet.

2.2.2 Stakeholder IdentificationAll problems or business situations have clear-cut owners or people and systems that get impacted. After having figured and studied the problem area, it would be the BA’s agenda to figure out the entire list of stakeholders in the software solution irrespective of the size of impact on these stakeholders as at this stage, it would be too early to judge the same.

Artifacts/References: Organization Charts, Talks with Client Project Anchors (CPA)

of 34

2.2.3 Stakeholders AnalysisHaving got the complete list of all “affected” parties (People, Systems, Departments, Organizations, Policies etc), it is time to analyze and prioritize the list. This is an iterative process as the priority obtained at this stage can sometimes be almost reversed by the time the project comes to a completion. Nonetheless, this exercise is to happen in order to at least have a reference point at the beginning of the project.

Artifacts/References: Thorough study of artifacts from above sources coupled with logical grouping of data would lead to a draft analysis; this draft could be discussed with the CPA for validation.

2.2.4 Selecting the Techniques and ToolsHaving done the above activities, the BA is now ready for a “Smart” talk with all the stakeholders. The word “smart” has been exclusively chosen in order to clearly state the opposite of Dumb. This is very important as the stakeholders participate in the Elicitation process as one more “thankless” activity in their job and unless the BA speaks their language, emphasizes with their problem, shows concern for the area and is knowledgeable, they are likely to be turned off and reduce the affect of their participation. Being well equipped with knowledge it is now time for the BA to jump into the process of elicitation, there are various situation/context dependent techniques of elicitation, here we discuss most of them:

Elicitation Techniques can be broadly classified into two types based on the stakeholder’s participation.

2.2.4.1 Non-Congregational (NC) Elicitation TechniquesNC techniques do not require all stakeholders to participate at one point of time, it is more of batch/staggered way of gathering requirements. These techniques are strongly dependent on the BA’s skills. NC techniques require more time than the congregational ones. Here are some of the NC techniques

Interviews: This has been the oldest technique of gathering requirements. It is highly centered on the communication and domain knowledge of the BA. The BA has to know exactly what to ask from which of the stakeholders. This process also involves setting up interview sessions. The drawback of this process is that the BA usually gets only one go at the interview and getting back to the stakeholders and establishing the context is difficult. BA plays the role of an organizer and facilitator of these interviews.

Questionnaires: This is not an independent technique for elicitation and particularly not with a single questionnaire. It can be used as a precursor or as a follow up to any of the other techniques. Framing the right questions and analysis the answers rightly in order to come up with a next set of questionnaire which is not repetitive is a relatively high skill job.

Task Analysis: Using existing documentation the BA can break up the tasks further in order to seek the right details from the process owners. This process also brings up loose ends in the existing process.

of 34

Introspection: Easier said than done, but asking the basic questions of Why, What, Who, When, Where and How about each problem statement or business process can lead to building of the problem area along with intuitive solutions which can then be validated with the CPA.

Observation: Again a BA skill centric technique, which involves the BA to mutely observe the process being carried out in order to build draft process documentation or to build material for asking the right questions such that problem knowledge can be obtained fully.

Boombox technique: This is a technique which involves the stakeholder executing the process to speak out every action that is performed while fulfilling the process. Doing so most of the times brings out the minutest details which by means of observation or documentation study would have been lost. The logic being that, as the process owner is to explain every step and the radical behind each step, details which otherwise are not “spoken” of are highlighted.

Apprenticing: Hands-On is most desirable way of gathering process and problem knowledge as the BA does the job coming from a third party perspective. It is but human to get used to minor problem areas over a period of time and thus such problems never surface when the owners walkthrough the process.

For eg. After keying in information in multiple text boxes, the clerk had to click a “Next” button using a mouse, the clerk had no issues with this but when the BA performed the same process, it was realized that tabbing and pressing enter to do the same action would save processing time.

Prototyping: Quick prototyping has always helped the stakeholders to agree to disagree with the solution space. Quick, Modular, Dummy but “functional” walkthroughs have led to right recognition of problems and solutions.

2.2.4.2 Congregational Elicitation TechniquesAs the name suggests, Congregational techniques require majority if not all stakeholders to participate at one point of time, it is more of one time way of gathering requirements. These techniques are not as strongly dependent on the BA’s domain and analysis skills as they are on the BA’s meeting facilitation skills. Here are some of them:

Goal Based Approach: This is a top-down approach of solution development. All organizations have goals, breaking these goals into smaller, manageable and operational pieces defines the scope of the problem and in doing so requirements can be gathered for these smaller scopes and assembled later on.

Card Sorting: This has been the analyst’s favorite way of familiarizing with the domain. All participants are required to come up with domain entities and then sort them based on the relevance. These are then sorted and relationships built between the entities so that the data structure analysis can be done.

Brainstorming: All stakeholders join in on calls. White boarding sessions, face-face meetings etc to brainstorm on the definition of the problem as well as the solution. Getting stakeholders from different levels of business to participate in such sessions usually gives rise to “co-created” solutions.

of 34

Joint Application Development (JAD): Logistically, one of the biggest nightmare but end result of this exercise usually is a “miracle” for most organizations. All stakeholders (Business, Technical, Maintenance, Development teams, Project Management etc) get into the session with the objective of solving the problem and usually end up doing so. All feasibility analysis is carried out in the session as all stakeholders are present. Requirements gathered in such sessions are not heavy on problem documentation but more so on solution documentation. JAD projects are applicable to industries where Time to Market is very less.

Requirements Workshops: These are predecessors of JAD sessions, these do not involve all the stakeholders to be available for the workshop, and usually it is a community of stakeholders for which the workshops are held. For eg, A workshop of all top and middle management followed by operational experts and then followed by development teams. Usually, output from one workshop forms an input into another one. Thus the requirements are elicited in a sequential manner and built over a series of workshops.

Scenarios: The basis of this technique “What if?”. The BA goes about using permutation and combination approach to present to the stakeholder all scenarios and the stakeholders verify each scenario and help elaborate it with details, in this process all the EXCEPTION requirements of the solution are obtained.

Viewpoints: The problem/solution area can be modeled using multiple viewpoints, it is a common practice to model requirements through multiple system viewpoints, multiple interface viewpoints so that these views provided by different stakeholders can be streamlined to form one solution.

2.2.5 Eliciting RequirementsOnce the techniques are selected based on the project context, the actual act of eliciting the requirements can be done. Here are some pointers while carrying out this process:

Be Aware of unrealistic demands by the stakeholders: Although it is advisable to the BA not to have an implementation view at the time of requirements gathering, it helps many a times to interrupt during the requirements gathering process if “unrealistic demands” pop up in the sessions. This again is subjective as to what “unrealistic” means but using the project constraints such as budget, time, resources and not so much technical feasibility, a demand can be classified as unrealistic and this is to be communicated rightly in the session so that the session may not get off on another tangent without the feasibility of implementation. It is here that the BAs role as a X-Analyst comes in handy. X standing for Business, Financial, Technical etc.

Keep Organizational and Legal constraints in mind: Each Stakeholder has a boundary within which he/she may dictate the requirements, this is to be considered as a stakeholder belonging to process A cannot dictate requirements for process B and if there are any interdependencies then these have to be mutually sorted out. Recording source and destination of requirements helps alleviate this problem. Legal constraints too play a spoil sport at times and this may be overlooked by the stakeholders due the lack of knowledge or enthusiasm of building the solution, the BA is to handle on this too.

Obtain System Stakeholders’ inputs: It is a good practice to gather first level of requirements without “intervention” from system developers in order to avoid solution

of 34

bias but it is also a good practice to obtain inputs on system level details from the owners of the system, not from a technical feasibility but more from a data consistency feasibility.

Define the Operating environment of the system: The solution developed cannot be developed to work on all platforms, work with all operating systems etc. All this is a business requirement wherein based on customer’s customer requirement parameters like OSs, Interfaces, Software dependencies etc are defined at the requirements stage itself. This may even lead to development of multiple versions of the solution (eg Windows specific and Linux specific).

Record source and rationale for requirement: For all purposes of traceability, it is advisable to record the source and rationale for requirement. This information is of help during the requirements prioritization stage.

Usage of visually clear modes of communication: It is advisable to use visuals exclusively during this stage. This leads to pin-pointing of error in the process. Usage of tools like PowerPoint, Whiteboards, Visio diagrams and means like teleconferences, charts etc are advised.

Avoid Stakeholder conflict: At times, views and goals of stakeholder’s conflict with each other, such situations are to be handled by keeping in mind the organizational goals, political and legal conditions in mind. It is a purely “mediator” role that the BA plays in such cases.

Not all of the techniques describes above can be used in all activities of Requirements Elicitation, Table 1 shows the suitability of techniques to elicitation activities. The Tick marks indicate the suitability of Technique to an activity in elicitation.

Table 1: Elicitation Activities to Elicitation Techniques suitability

of 34

Application of Elicitation Techniques based on Size of Change or Requirements and Number of Users. The Table below shows the distribution of techniques on the two simple dimensions.

Figure 1: Applicability of Elicitation techniques on dimensions of Size of Change and Number of Users.

2.2.6 Methodology based Requirements ElicitationRequirements Elicitation as such has no methodology developed solely for it, what practically happens is that the artifacts from other stages of the requirements gathering process such as that from requirements analysis and specification are widely used to assist in the elicitation process.

Thus, the BA may end up using Data Flow Diagrams (DFDs) and Entity Relationship Diagrams (ERDs) which are artifacts from the widely used Structured Analysis and Design (SAD) methodology used for analysis, specification and design of software systems. Similarly, Unified Modeling Language (UML) diagrams such as use cases and sequence diagrams get used exclusively in the elicitation process although these are artifacts of Object Oriented (OO) methodology of requirements specification.

2.2.7 Tools Support for Requirements ElicitationIn the earlier years of Requirements gathering process, stress on development of standard templates for requirements elicitation led to templates like Volere Requirements Specification template, which guides the BA in gathering the information such that these templates can be filled. Similarly templates for use case description give a clear guidance to the BA for seeking information.

Although research is continuing on improvising these templates, a faster progress in being made in the area of providing an environment to populate this information. This

of 34

usually ends up in building of a tool (client or server based) and also leading to usage of readily available modes for facilitating elicitation of requirements. Some common tool/toolsets for elicitation are:

DOORS

CaliberRM

RequisitePro

These are tools which are aimed at holding various levels of software solution information such as High Level Design (HLD), Architectural Design and Low Level Design (LLD) artifacts. These just have some placeholders or features to facilitate elicitation.

On the contrary, there are elicitation specific tools available in the market, these are:

Objectiver

ART-SCENE

AbstFinder

AMORE

TeamWave

GroupSystems (As the name suggests, it is a combination of tools and modes)

Some common features required in elicitation tools are:

Should be able to support goal driven requirements analysis

Should allow for multiple views on documents with easy navigation

Should allow for Completeness and consistency checks

Should allow for Traceability inside models, source, output documents

Simple-to-use for specifying and parsing Use Cases

Should allow for automatic generation of normal and alternative course scenarios from Use Case specifications

Should allow guided scenario walk-throughs using Web-enabled tools

Should support multimedia representation of scenarios to improve discovery of requirements

Should support for standard requirements processes such as VOLERE

Should be easily queryiable

Should allow for portability of models into down-stream tools

On a practical note, MS Office suite (Word, PowerPoint, Visio and Excel) seem to be the most common tools aiding in preparation and display of documentation for elicitation with a very savvy usage of teleconferencing, e-mailing, video-conferencing, White boarding etc.

of 34

Checklist to validate Completeness and Correctness of Elicitation Stage.

Subject/

CharacteristicsCompleteness Correctness

Stakeholders

-Has the list of stakeholders been reviewed for completeness?-Have inputs been taken from all stakeholders in the process?

-Has the list of stakeholders been reviewed for correctness?-Have inputs been cross-validated by different groups of stakeholders?

Primary Systems

-Has the list of systems been reviewed for completeness?-Have inputs been taken from all system owners?

-Has the list of systems been reviewed for correctness?-Have inputs been taken from all system owners?

Business Processes

-Has the list of impacted business process been reviewed for completeness in terms of scope?-Has impact of all business processed been considered?

-Has the list of impacted business process been reviewed for correctness?-Has impact of all business processed been cross-validated by business owners?

Interacting Systems

-Have all the interacting systems been listed?

-Has the impact on all the interacting systems been taken into account?

Regulations-Have all the regulations impacting the business process been considered?

-Has the impact of all the regulations been cross-validated?

Issues

-Have all the issues been resolved?

-Has the issue resolution been validated for correctness?-Are there any newer issues evolving out of issue resolution?

of 34

3 Requirements AnalysisRequirements Elicitation process is inherently spontaneous in nature, both the client community and the analyst community do not stifle the thought flow during the elicitation process for the fear of losing out on requirements. Elicitation is viewed more as an exercise to get a dump of all ideas, requirements, viewpoints and constraints. Requirements obtained from this stage then have to be categorized, grouped, sorted, checked for conflicts, checked for logical omissions, overlaps and redundancy. These set of activities are grouped to form the Requirements Analysis stage of requirements gathering.

All the requirements have to then be sorted, logical gaps are to be filled, conflicts are to be resolved and then prioritized, this is called Analysis of Requirements. The end result of this exercise is a list of prioritized, complete and consistent set of requirements

Though each BA has his/her own style of analyzing the requirements, they all seem to inherently follow these basic guidelines.

3.1 Basic guidelines for Requirements Analysis

3.1.1 Establish System Requirements boundaryWhile rolling out requirements, the stakeholders cannot or do not distinguish between software and process requirements, it is the analyst who has to figure out whether the requirement is that of the software or a process, this can be done by posing some basic questions against each requirement:

System functionality scope: All systems are created to cater to a certain business functionality. If the analyst is working in an environment, which already has multiple systems to cater to differing business processes, then studying the functionality support of each system can be a good pointer to defining the scope of the system. For eg, if the analysts is gathering requirements for a system which was designed to assist the company’s financial transactions, then gathering requirements related to HR details (which do not have a financial bearing) of the company would be out of scope for this exercise.

Are all the parameters for the system readily available? For the system to move from one state to another, certain parameters (Data, Events et) are to be available, if the availability of these requires human intervention then semi-automating or making such tasks manual would be advisable especially is a subjective decision input is required. Such an analysis provides input to level of automation of the process that can be achieved by the software solution.

Is the requirement that of an external system? In this era of outsourcing parts of the business process, the BA quite often comes across requirements on systems which are outside the purview of the system under consideration, such cases warrant the BA to document this as a constraint rather than supplying further requirements to this external system unless warranted.

of 34

3.1.2 Cross-check with a generic Checklist for requirements analysis

Each of the requirement obtained can be cross checked with a generic checklist that the BA can maintain, some common checks are listed in the Table below:

Question If Answer is –Yes If Answer is -No

Does the requirement have Design/Implementation information?

This is not a requirement but more of a solution posed as a requirement, BA can check to obtain the requirement from this rather than the solution

Include as Requirement

Is the requirement at atomic level?

Include as Requirement Break Further by removing "and" words

Is the requirement a “Nice to have”?

Mark as LOW Priority Include as Requirement

Is the requirement in line with the customer’s business goal?

Include as Requirement Mark as goal conflicting requirement

Is the requirement realizable? (Technically, Financially, Time-wise)

Include as Requirement Mark as applicable risk-Technical Infeasibility-Financial Infeasibility-Schedule Infeasibility

Is the requirement testable? Include as Requirement Needs to be reworded or removed

Is the requirement verifiable? Include as Requirement Needs to be reworded or removed

Is the requirement validtable?

Include as Requirement Needs to be reworded or removed

Does the requirement compliment the current systems’ business objective?

Include as Requirement Mark as out of current system scope and highlight the risk if not realized

Does the requirement breach any legality or contract?

Highlight as Contractual or Legal Risk


Does the requirement cross the established system boundary?

Mark as out of current system scope and highlight the risk if not realized


Does the requirement depend on future systems or processes?

Mark as out of current system scope and highlight the risk if not realized


Is there an already existing functionality for the requirement?

Mark as Existing functionality and look at reuse


of 34

Question If Answer is –Yes If Answer is -No

Is the requirement countering any already existing functionality?

Mark as countering existing functionality and look at solution


Table 2: Basic Checklist for Analyzing Requirements

3.1.3 Figure out Overlaps and Conflicts and Resolve them.A simple matrix of Requirements Vs Requirements can be plotted to gauge the percentage of Overlapping and percentage of conflicting requirements. These can then be taken back to the stakeholder for resolution, negotiation and also overlap reduction.

A Simple tool used by the BA to gauge the conflict and overlap percentage. All requirements are plotted on Rows and Columns of a spreadsheet. Each requirement is compared with every other requirement and subjectively analyzed to be either Conflicting, Overlapping or Independent to the requirement being compared to. A simple matrix as shown below is obtained which would provide the results using the formula below. Conflict and Overlap scores can be calculated for each requirement and necessary action is taken to mitigate it during the negotiation process.

Req 1 Req 2 Req 3 Req 4Req 1 X C I IReq 2 C X O IReq 3 I O X IReq 4 I I I I

Conflict % = [(No. of Cs) / (Total No. of requirements-1)] * 100

Independence % = [(No. of Is) / (Total No. of requirements-1)] * 100

Overlap % = [(No. of Os) / (Total No. of requirements-1)] * 100

These scores are calculated for each Requirement.

Eg. In the above table, the scores for Req 1 are:

Conflict % = [(1)/(4-1)] * 100 = 33%

Independence % = [(2)/(4-1)] * 100 = 66%

Overlap % = [(0)/(4-1)] * 100 = 0%

Classify requirements using a multi-tier approach

All requirements can be classified as falling in one of the following layers. By doing so, a BA can group requirements.

Front End

Processing Layer

Back End

Communication Layer

Security

Performance

of 34

The “thickness” of each of these layers in terms of requirements would indicate the completeness of the requirements. For eg. a simple web page would have higher number of Front end requirements compared to a online purchase web page which would have a heavy security, processing, and communication requirements.

This classification also maps well to the stakeholders responsibilities, for eg Security requirements would be looked into by the legal team, Front end requirements by the Usability team and so on.

3.1.4 Plan for conflict resolutionHaving obtained the conflicting requirements from the earlier stage, they need to be resolved, this primarily has 3 distinct sections:

Explanation and Options: This involves presenting the conflicts and also possible solutions to the stakeholders.

Discussion: Having presented the explanation, sufficient time is to be given to stakeholders to discuss on resolving the situation.

Resolution: Each solution is then analyzed and optimal solution is documented.

3.1.4.1 “Publicize” the conflict resolution outcomeNot all stakeholders would attend the resolution sessions, nonetheless, the resolution option, along with rationale is to be publicized, this is usually done through electronic media such as e-mail, virtual notice boards etc and sign off is sought.

3.1.5 Assess requirements riskAlthough it has been warned right from early stages that requirements is a process which is independent of implementation, having a “smart” implementation foresight often solves problems which would eventually have been encountered during the implementation process. Needless to say this activity highlights various risks at an early stage so that mitigation may be carried out for the same. Various risks (along with examples or instances) that can be identified by the BA are:

Implementation Technology Risks (What if the requirements are gathered assuming integration with legacy systems whereas adaptors for these systems are not available)

Scalability Risks (What if the NFRs indicate a spike in instances of usage whereas the hardware or the software architecture is not consistent with this demand)

Performance Risks (Does the software architecture indicate requirement for performance tuning, this risk is coupled with the scalability risk)

Database Risks (Size, availability, quality of DBs)

Schedule Risks (Project slips, module slips etc)

Cost Risks (Time, complexity and out of scope requirements adding to project costs)

Dependency Risks (Inter-module, Inter-version, Environment dependencies)

of 34

4 Requirements Specification4.1 Software Requirements SpecificationWe’ve reached a stage in the requirements gathering process where we’d be documenting the gathered requirements. These specification documents would be referral documents from hereon and thus they need to be lucid, unambiguous, consistent, traceable, comprehensible and should contain the right level of details. Quality attributes of requirements are discussed separately in the section Quality of Requirements.

Though the processes of Requirements Elicitation, Requirements Analysis and Requirements Negotiation can happen in parallel with specification, there is a good amount of dependency on the completion of these processes before the BA can completely specify the requirements.

4.2 Contents of Software Requirements Specification (SRS)

An ideal SRS comprises of requirements which fall under two categories:

Functional: A functional requirement describes how a user will interact with a system (user interface issues), how someone will use a system (usage), or how a system fulfills a business function (business rules). These are often referred to as functional requirements.

Non-Functional. A non-functional requirement describes a technical feature of a system, features typically pertaining to availability, security, performance, interoperability, dependability, and reliability. These could even be viewed as constraints of the system.

What is not a part of SRS

It is not only desirable to know what constitutes an SRS, but also very important to know what should be avoided in an SRS. Here’s a list of things which should not be included in an SRS:

Design Information: This is the last information that is to be included in an SRS. It has been maintained from inception that requirements just specify “what” is to be done as opposed to “how” it is to be done. Design information in the form of class diagrams, component diagrams, deployment diagrams etc clearly specify the “how” part and thus have to be excluded.

Quality Assurance Plans: These not only have a different audience, time wise too, these would not be fully in place at the requirements stage. Eg of such information are Verification and Validation Plans, Test Plans, Configuration managements plans etc.

Project Planning Information: This too has a separate audience. Eg of such information are Project Schedules, Costs, Staffing Plans, Reporting structures and procedures for project execution etc.

of 34

4.3 Questions an SRS should addressAn SRS is the linking document between the Customer and the Software Development team. SRS fully represents the scope of the solution that will be built. An ideal SRS is written with the intention of answering the following six questions:

1. Who: The SRS usually begins with the list of all users (Organizations, Departments, Roles and Systems) of the solution. This helps in figuring all the interfaces that the solution would have. Representation of such a diagram usually referred to as an Organization Diagram can be done using simple blocks to represent entities (Organizations, Departments, Roles and Systems) and named connecting arrows to depict the relationship between these entities.

2. Where: Even software built for global use has good amount of localization, localization can be in terms of adhering to a country’s legalities etc. Thus it is imperative to have a representation of such a geographical distribution of roles and instances of the solution being used. Such a representation again can be done using simple blocks to represent entities (Locations, Organizations, Departments, Roles and Systems) and named connecting arrows to depict the relationship between these entities.

3. What: This aspect of the SRS defines the project scope. It comprises of the high-level view of the processes to serve which the solution is being developed. Representation of such high-level processes is done using a diagram known as Context diagram. The objective of this diagram is to provide to the reader a high level view of the problem or solution that is being modeled.

4. Why: This aspect of the SRS provides the business case or a simple justification of each of the “What“ models that are depicted in the SRS. Representation of this is usually done in Natural Language.

5. How: This compliments the “what” information of the SRS. This is not to be confused with technical solution (eg, Customer class shall call Vehicle Number class) but it simply details out the aspects the solution that is being developed. Detailing can be done for

a. Process flows using Workflow Diagrams (WFD): These explain the sequence of activities and events that are required to accomplish a process.

b. Data Flows using Data Flow Diagrams (DFD): These explain the operations done to data as it flows through the process.

c. Relationship of domain entities using Entity Relationship Diagrams (ERD): These list and clarify all the domain entities and the relationship between each of them.

d. Functionalities that are to be developed can be represented using Usecase Diagrams (UCD): This is the next level of detailing of the system functionality pertaining to the WFDs. UCDs follow the UML notation and clearly represent at a high level the complete list of functionalities that are to be developed in the solution. These diagrams also depict the relationship between the usecases and actors (as specified in “who”) of the system.

of 34

e. The functionalities depicted in usecases are detailed out using Flowcharts or Activity Diagrams. These diagrams explain the lowest level of process execution and compliment the UCD. Activity diagrams show the tasks in sequence that need to be carried out in order to accomplish the use case functionality.

6. When: The state of the system or process undergoes change either due to an event or an intervention. The event can be time based or dependent on other events, Intervention can be by the users of the system (Roles, other systems etc). Such information is built into the WFD, DFD, UCD and Activity Diagram. Usage of State Transition Diagrams (STD) is an exclusive way of depicting this.

Requirements Types

Contents Mode of Representation

Functional Requirements

All information that would help in understanding and building the desired solution?

-Natural Language- Context Diagrams

- DFDs- ERDs- WFDs- UCDs- Flowcharts/Activity Diagrams- STDs

Non-Functional Requirements

What are the present and future constraints on the system

-Natural Language

Table 3: Contents of a SRS

4.4 Notations Vs Methods/ApproachesVarious diagrams mentioned above are examples of notations. The BA may use these notations as per requirement of the project in conjunction with natural language so that the requirements specification is more lucid.

Methods or Approaches are a collection of such diagrams and these inherently also suggest a systematic way or flow of depicting the requirements. Thus the BA may either use a combination of notations in the SRS or may adhere to various available approaches to draw out the SRS.

Various Requirements Specification Approaches exist today, even explaining the base methodology of these is beyond the scope of this material, it is at the least advisable to know what exist, these are:

Categorization SRS Approaches

Object Oriented Coda’s Object Oriented Analysis (COOA)

Jackson’s System Development (JSD)

Entity Relationship Modeling (ER)

of 34

Industry Definition (IDEF)

Function-Oriented

Problem Analysis

Data Flow Diagrams (DFD)

Structured Requirements Definition (SRD)

Structured Analysis and Design Technique (SADT)

Structured Analysis and System Specification (SASS)

Modern Structured Analysis (PSL/PSA)

State Oriented Finite State Machines

State charts

Requirements Engineering Validation System (REVS)

Petri nets

Table 4: SRS Approaches

4.5 ToolsSome common tools used in the industry to model requirements are listed below:

Product Vendor

WBI Modeler IBM

Requisite Pro IBM

ARIS IDS Schemer

Cape Vision Filene

System Architect Teleological

BizTalk Microsoft

Corporate Modeler Case Wise

Provision Performa

MEGA Suite MEGA

Define IT Borland

Prophesy Sofia

Raven Raven flow

4.5.1 Tool Selection Checklist Here are a list of things that can be used to select the tool:

Does the tool allow for Requirements derivation (req. to req., req. to analysis/text)

Does the tool allow for Requirements Flowdown

of 34

Does the tool allow for Input document enrichment/analysis

Does the toll allow for Automatic parsing of requirements

Does the tool allow for Interactive/semi-automatic requirement identification

Does the tool have Batch-mode operation

Does the tool allow Requirement classification

Does the tool allow for Bi-directional requirement linking to system elements

Does the tool allow for Capture of allocation rationale, accountability, test/validation, criticality, issues, etc.

Does the tool Identify inconsistencies (orphans, ...)

Does the tool allow for Verification of requirements

Does the tool capture History of requirement changes, who, what, when, where, why, how

Does the tool allow Baseline/Version control

Does the tool allow for Access control (modification, viewing, etc.)

Does the tool have Standard specification output, Templates

Does the tool allow for Quality and consistency checking (spelling, data dictionary,...)

Does the tool have Presentation output

Does the tool have Custom output features & markings (definable tables, security marking)

Does the tool have other ad hoc queries & searches

Does the tool have Interfaces to Other Tools

Does the tool have External Applications Program Interface available

Does the tool allow for Import of existing data from various standard file formats

Does the tool have Intra-tool communications

Does the tool allow for Exchange of information between same-tool different installations

Does the tool operate on Multiple Platforms/Operating Systems?

Does the tool support Single user/multiple concurrent users

What are the Memory requirements

What are the CPU Requirements

What are the Disk space requirements

What types of User Interfaces are available

Does it have a Web browser interface?

What about Support and Maintenance

What about Warranty

What about License policy (Network, Node Locked,..)

of 34

What about Maintenance & upgrade policy

Does it have On-line help

Does it come with Phone support

Does it have a Support users group

Is there Training available

Are there Tool-specific training classes

Is Training available at customer's location

What is the Recommended training time

4.6 Dos and Don’ts1. Define Standard Requirements Templates for Describing Requirements: There

are several industry standard requirements specification templates that can be used directly or with minor modifications to suit any project. This is the first task that the BA can do before beginning the requirements gathering exercise. The BA may also develop a custom requirements specification template using sections from various templates. Some standard requirements templates readily available are:

Volere Requirements Specification Template

Department of Defence – DOD-STD-2167A

IEEE – Std 830-1993

2. Use Diagrams Appropriately: Various diagrams mentioned in Section 5.3 can be aptly used to supplement the natural text in order to bring in completeness in the specification.

3. Specify Quantifiable requirements: Most Non-Functional Requirements can be quantified, eg. Response time should be less than 5s rather than response time should be low.

4. Use simple, consistent and concise language: Usage of acronyms and industry terms has to be explained, all terminology is to be used consistently across the document.

5. Complete the Puzzle: Cover the answer to six questions with appropriate references between diagrams and sections.

6. Do not include design level details: like component diagrams and deployment diagrams

of 34

5 Requirements ValidationRequirements Validation is the process of ensuring that the set of requirements is correct, complete, consistent and verifiable

Once the requirements are specified, the SRS is to be validated for understanding, correctness, completeness and verifiability by various stakeholders. Here are a set of activities which are carried out to validate the requirements

5.1 Completeness of SRS as per template The SRS is to be checked with the SRS template (Standard or Customized) for

any missing information. This is the first level of validation that can be performed. Data can be missed in the SRS either due to

o Non-applicability: A field from the SRS template may not be applicable to the project, This has to be rationalized with an explanation and if found repetitive should be used as feedback to revise the SRS template.

o Unavailability: This indicates incompleteness of the SRS

o Overlook: This requires the BA to gather and fill up the SRS.

Pros: Cost and Time Effective

Cons: Analyst Bias sets in

5.2 Requirements ReviewsRequirements Reviews by multiple stakeholders is the best way of getting the requirements validated. Stakeholders can be Business groups, Peer groups (BAs), System Architects, Developers, Program Managers. Review by these stakeholders is to be in terms of understanding, completeness, consistency and clarity.

Pros: Cost Effective

Cons: Resource Intensive (Availability and response of stakeholders)

5.3 PrototypingCertain unclear requirements (mostly Interface requirements) are best understood if prototyped with dummy data. Even cases of unclear transaction requirements are good candidates for prototyping.

Pros: Higher response rate from stakeholders

Cons: Costly and Time consuming

5.4 Model ValidationEach of the models used in the SRS have their own static validation steps. For eg, Below are some model validation steps for an activity diagram

Do all the activities have an incoming connector?

Do all the activities have an outgoing connector?

Do all Decision points have at least two outgoing connectors?

of 34

Is there at least one starting point?

Is there at least one ending point?

Such validation steps can be used to measure the completeness of a Model.

Pros: Micro-management of quality aspect

Cons: Time consuming

5.5 Acceptance TestsThese are draft test plans for the requirements in the SRS. These can be created in collaboration with the testing team. The concept is that unless a requirement can be verified by a test case, it is invalid.

Pros: Generation of draft test cases

Cons: Time and Resource dependent

Summary of Analysis, Specification and Validation as checklist for quality.

Metrics for this section like # of stakeholders

of 34

6 Requirements Management6.1 Overview“Requirements management is the science and art of gathering and managing user, business, technical, and functional requirements within a software development project. “

It is referred to as art because the initial interdependencies between the requirements are established or validated by the analyst. It is referred to as science because it uses decision tree logic, traceability concepts and has an engineering view to it in terms of hosting, establishing linkages and managing the requirements.

6.1.1 TraceabilityIt is the ability to describe and follow the life of requirements, in both forward and backward direction, ideally through the whole system life cycle.

Requirements traceability is achieved through association of related information items such as:

Requirements and related requirements (Parent, Child, Dependent etc)

Requirements and related system components satisfying those requirements (Eg. Requirements to Classes)

Change proposals and requirements which they intend to change

A decision, it’s origin, rationale and the assumptions on which requirements are based

Requirements and test cases which would verify the requirements

System components and resources needed to implement requirements

Traceability Types

Figure 1: Traceability Types

The above figure depicts the types of traceability that can be established. It is explained in brief as follows:

Pre-Traceability: This is the traceability which is involved in the production of requirements. i.e. traces are established between domain document references and the

Domain Documents

Requirements Documents

Design Documents

Backward Traceability

Forward Traceability

Forward Traceabili

tyBackward Traceabilit

y

Pre-Traceability Post Traceability

of 34

statements that go into the SRS. There can be any type of mapping between such documents (one-one, one-many, many-one or many-many). Pre-traceability can further be classified into Backward and forward traceability. As mentioned in the earlier sections the SRS becomes the referral document for a software solution design, linking the statements of requirement from the SRS to their sources (documents, elicitation activities, business objectives etc) is termed as backward traceability whereas the converse in known as forward traceability.

Post Traceability: This is the traceability which is involved in the deployment of the requirements. All traces or maps from the requirements statements to any of the design documents extending up to test cases and release plans constitutes post traceability. Post traceability also is classified further into forward and backward traceability. Forward traceability is the traceability between any of the requirements statements from an SRS to all documents which are a part of later stages in the software development lifecycle (SDLC).

6.2 Change Management“Change is the only constant” – change in requirements cannot be avoided as requirements may undergo change even before implementation. What is critical though is figure out the ripple effect of the change required. Change management depends largely on the traceability practice followed in the development. Here are the steps followed in order to incorporate a change request:

Analyze the problem and Specify the change

Analyze the change in terms of cost and time parameters

Validate the change request

Obtain the directly affected requirements from the trace matrix

Obtain dependent requirements

Assess costs of change

Assess cost acceptability

Implement Change

Once implemented, update or version all the affected, set of requirements and design documents.

6.3 ToolsSome commonly used RM tools in the market are:

Product Vendor

CaliberRM Borland

CORE Vitech

Doors Telelogic

IRQA TCP

Profesy Sofea

Optimal Trace Compuwar

of 34

e

Rational RequisitePro

IBM

Serena Dimensions Serena

of 34

7 Quality of RequirementsDevelopment of the software solution is primarily based on the requirements document. The development team, testing and maintenance team all assume that the requirements document is “correct”. And as the requirements document is the source for all activities along the SDLC, every requirement has a ripple effect on the activities of the SDLC and more so the ripple effect is unilateral i.e. a correct requirement will produce a small ripple with the requirement being fulfilled in the solution whereas an incorrect requirement can produce a huge ripple due to the entire set of incorrect design documents, incorrect test plans etc.

This makes it imperative to have the Requirements Documents of as high a quality as possible.

7.1 Approaches to maintain Quality in RequirementsThere are two approaches to check the quality of requirements

7.1.1 Constructive ApproachConstructive approach aims to ensure quality during the creation of the documents itself. It is more of quality by prevention rather than quality by correction. Thus quality is ensured at each step of the requirements engineering process, it is explained below:

Step 1: Requirements Elicitation: Quality is ensured in the elicitation process by performing it (elicitation process) with a view to satisfy the following quality parameters:

Comprehensible

Completeness

Verifiable

Feasibility

Correctness

Step 2: Specification Techniques: SRSs are authored with the intent of fulfilling the following quality requirements.

Attribute Explanation

Correctness Each requirement stated should be such that it is required to fulfill a certain purpose which is validated by the user/customer

Unambiguity The requirements should have only one possible interpretation. It is possible however that the same requirement may be viewed differently by different stakeholders but will have to fulfill the same purpose

Completeness All important elements that are relevant to fulfill the different user's tasks should be considered. This includes-Functional Requirements-Non-Functional Requirements-Interfaces to other systems-Responses to all scenarios-Definition of all relevant terms and measures

of 34

Attribute Explanation

Consistency All terminology used in the requirements should be consistent

Importance All requirements are to be ranked based on their importance. Requirements which are parent requirements to many requirements would be of high importance

Verifiability All requirements are to be verifiable. There should be some way for a machine or a human to check whether the requirements has been fulfilled or not

Modifiable The structure of the requirements and the requirements specification should allow for easy integration of changes

Traceable All requirements should be traceable, both forward and backward

Comprehensibility

The requirements should be specified in a way that should be understood by all groups of stakeholders

Feasibility All requirements in the SRS at a higher level should be implemental with the given constraint of technology, cost and time

Right Level of details

The requirements should have the right level of details for designers rather than having design level details

Step 3: Prototyping: Clarity in requirements is obtained by building quick prototypes of the solution wherever possible. Prototypes with dummy data and transactions aid in refining requirements from users thereby improving on the quality aspects as mentioned above.

7.1.2 Analytical ApproachThis is more of a quality assurance approach rather than preventive way of quality maintenance. It involves the following activities:

Requirements Inspections: Requirements can be subject to peer based inspections. BAs have their own ways of inspecting documents, When applied to a project out of context (someone else’s project), these inspections work well as there is no bias play.

Requirements based Testing: Although Test cases cannot be executed unless the solution is developed, at the least, they can be developed during the requirements stage itself. Testing teams can prepare requirements based test cases to pin-point requirement gaps and to assess requirements for verifiability.

Here are some generic questions that the BA can seek answers for to analyze the quality of requirements:

Does each requirement have a quality measure that can be used to test whether any solution meets the requirement?

Does the specification contain a definition of the meaning of every essential subject matter term within the specification?

Is every reference to a defined term consistent with its definition?

of 34

Is the context of the requirements wide enough to cover everything we need to understand?

Have we asked the stakeholders about conscious, unconscious and undreamed of requirements?

Does the specification contain solutions posturing as requirements?

Is the stakeholder value defined for each requirement?

Is each requirement uniquely identifiable?

Is each requirement tagged to all parts of the system where it is used? For any change to requirements, can you identify all parts of the system where this change has an effect?

of 34

8 REFERENCES