Requirements Elicitation

Requirements Elicitation

1. Types of Requirements

   • What is requirement?
   • A description of a stakeholder need    A condition or capability needed by a stakeholder to solve a problem or achieve an objective.    A condition or capability that must be met or possessed by a solution or solution component to satisfy a contract, standard, specification, or other formally imposed documents.    A documented representation of a condition or capability as in the above bullet points    
   • Problem Domain
     • Business Requirements: addressed by the Business Case           –  Stakeholder Requirements: addressed by Requirements Elicitation                            
     • Business Requirements
     • Stakeholder Requirements
   • Solution Domain
     • Functional Requirements: derived from Stakeholder Requirements through Requirements Elicitation                                                
     • –  Non-Functional Requirements: derived from Stakeholder Requirements through Requirements Elicitation
     • Transition Requirements: based on the implementation situation, based upon whether or not an old system is undergoing replacement
     • Functional Requirements
       • Describes capabilities that the information system will provide.                              
       •       –  How a person or system will interact with the proposed solution – a specific system action or response.                 
       •   –  A standard that must be complied with.              –  Covered by the (a) Requirements Elicitation and  (b) Requirements Analysis knowledge area.             
     • Non-Functional Requirements
       • Describes environment conditions under which the solution must remain effective or qualities that the system must have
       • Also called as Quality of Service or Supplementary requirements
       • Covered by the Requirements Analysis knowledge area. 
       • Environmental Requirements
         •       These are environmental constraints imposed by the atmosphere outside of the system boundaries.    
         •       Common environmental requirements are: – Audit – Localization – Legal/compliance    
         • Audit
           •       Audit requirements define information that the process or system must produce when required by an outside agency.    
         • Localization
           •       Solutions implemented across multiple cultures may include support for multiple languages, date and currency formats, number displays, text sorting etc    
         • Legal
           •       Legal or regulatory requirements include rules and regulations imposed by governments or other regulatory bodies outside the enterprise.    
       • Interface Requirements
         • Interface requirements define the interactions between computer systems.    
         • Hardware Interface
           •       Hardware interface requirements describe the characteristics of each interface between the system and hardware components of other systems.    
           •       Example 1: An ATM that connects to a bank’s back end servers to provide information related to an account’s balance and transactions and provides facilities to withdraw money Example 2: Process controllers that sense various parameters of a process plant and send these to a computer system that controls the plant’s functioning    
         • Software Interface
           • Software interface requirements describe the connection to other software components e.g., databases, operating systems, tools, libraries and commercial components.                         
           • The information should include the purpose of the message, as well as the data and control items exchanged.
       • Communication Interface
         • The requirement includes the services needed by external software components and the nature of the inter-component communications.    
         • The data shared across systems is identified and any new data sharing mechanisms are identified.    
       • Glossary
         •  A glossary defines terms that have special meaning to the organization. It is used by the project team to ensure consistency in the terminologies used. It also provide definitions of common problem domain terms for other project team members.  
       • Operational Requirements
         • Operational requirements define how the system will run and interact with operators. – Examples include how many users may use the system concurrently, user access requirements, and the maximum acceptable downtime.    
       • Privacy Requirements
         • Privacy requirements restrict the distribution of personal information without the express or implicit consent of the parties involved.    
         • describe what information is considered private and under what circumstances it may be made available to internal and external parties. —  are distinct from security requirements in that they presume that the parties in question have legitimate access.    
       • Performance Requirements
         • Performance requirements for various system components indicate how much information the system must be capable of processing in a given period of time.    
       • Quality Requirements
         • Quality requirements describe the designability, reliability, usability, maintainability, testability, scalability, and portability expectations for the system. These characteristics should be specific, prioritized, quantitative and verifiable.    
         • Maintainability requirements
           • describe how likely future changes to the solution are and what should be done to facilitate those future changes in the present system.    
         • Scalability requirements
           • describe the likely growth of use of the solution over time, allowing the project team to plan for increasing capacity.    
       • Security Requirements
         • Security requirements are important when the nature of the data that is traded is sensitive or access to the information must be either monitored or restricted.                   
         • Security requirements protects the data that the system uses or creates.    
         • —  They describe the potential risk that individuals will attempt to gain illegitimate access to information stored within the solution or that individuals with legitimate access will use the information in illegitimate ways. —  They include strategies to prevent access and mitigate the risks involved.    
       • Training Requirements
         • Training requirements describe the educational needs of stakeholders who will interact with the solution.                                                         
         • They describe the types of stakeholders affected, the changes from the present situation that each type of stakeholder will encounter, and how those stakeholders will be informed of those changes in a way that allows them to make effective use of the solution.
     • Transition Requirements

2. Techniques

   • Steps: Understand the overall scope          Selecttechniquetobeused               Decide which part of the scope will be covered by which technique                  Gather necessary supporting materials                  Schedule required resources (people, facilities, equipment)         Notify appropriate parties of the plan and firm up the plan    
   • Brainstorming
     • A team activity that seeks to produce a broad or diverse set of options through the rapid and uncritical generation of ideas.    
   • Document Analysis
     • A means of eliciting requirements of an existing system by studying available documentation and identifying relevant information.    
   • Focus groups
     •  A means to elicit ideas and attitudes about a specific product, service or opportunity in an interactive group environment. The participants share their impressions, preferences and needs, guided by a moderator.    
   • Requirements workshops
     • A structured meeting in which a carefully selected group of stakeholders collaborate to define and/or refine requirements under the guidance of a skilled facilitator.    
   • Surveys/Questionnaires
     • A set of questions sent to the stakeholders in order to collect responses from a large group in a relatively short period of time.    
   • Interviews
     • A systematic approach to elicit information from a person or group of people in an informal or formal setting by asking relevant questions and documenting the responses.    
   • Observation
     • Witness people performing their jobs and the flow of work through the business routine to gain an understanding of how the process works.    
   • Prototyping
     • Building a scaled down version of the system and demonstrating it to the users and soliciting their comments.    
   • Items to Consider
     • Tracing Requirements
       • Alwaysimportanttotracebackrequirementstothebusinessgoals/ objectives – otherwise can lead to scope increases, gathering of incorrect requirements or irrelevant requirements    
     • Capturing Requirement Attributes
       • Important to capture relevant attributes such as source, priority, value etc. to help manage each requirement through the life cycle                                        Important to capture relevant attributes such as source, priority, value etc. to help manage each requirement through the life cycle    
     • Metrics
       • Tracking the elicitation activity from start to finish and recording actual time taken would be required for (i) measuring performance, (ii) for future planning and (iii) for future estimations    
     • Data Dictionary and Glossary
       • Used by the project team to ensure consistency in the terminologies used. It also provide definitions of common problem domain terms for other project team members    

3. Inputs

   • Business Need, Business Case and Solution Scope
     • The Business Need is used to understand what information is required to be elicited from stakeholders    
   • StakeholderList,Rolesand Responsibilities
     • Used for identifying stakeholders who should participate in the elicitation activities    

4. Outputs

   • Scheduled Resources
     • Includes participants, locations and any other resources that would be needed for the elicitation activities    
   • Supporting Materials
     • Any materials such as documentation and demonstration systems, white boards, flip charts, template forms, pens etc. that would be required    
   • ElicitationResults
     •  Contains information gathered from the stakeholders – includes process, systems, procedures and other documentation, minutes of meetings, video and audio recordings of discussions and meetings etc.    
   • Requirements (Stated)
     • Requirements as stated by stakeholders without the use of any Information Technology jargon – Initial draft form    
   • Stakeholder Concerns
     • Includes issues, concerns, risks, assumptions, constraints etc. identified by stakeholders – Initial draft form