Common Definition Business Requirements are 1 An agreed upon description of user needs and the new system product capabilities and characteristics 2 Writt

							Common Definition
      Business Requirements are:
          1. An agreed upon description of user needs and the new system/product capabilities and
             characteristics
          2. Written in sufficient detail to permit development/procurement to proceed at an
             acceptable level of risk.
The Four Components of a Business Requirement Document include:
          1.   General System Requirements
          2.   Functional Requirements
          3.   Quality Requirements
          4.   Technical Requirements

The Need for Effective Business Requirements
      Good requirements ensure projects are successful, on time, come in at or below
      budget, deliver what is expected and perform as they should. Subsequent
      enhancements and bug fixes are not as costly.

Business Requirements Process
      Step 1 - Goals & Objectives/Feasibility
            Project vision and scope
                     If you do not know the goal, you can’t get there
                     If you cannot define what you need, the procurement will not provide the
                     answer
               Identify stakeholders
               Define the “now” work process
                     Present problems
                     List goals
                     Identify consequences and risks
               If not defined early, the wrong requirements can be costly to change
                     Embedded in design
                     Not discovered until testing
                     Mistakes snowball
                     Corrected in maintenance at higher rates
                     Amendment of contract for missing/incomplete requirements
      Sample Goals and Objectives from WIC RFP
   Agency Goals                                 Project Objectives
  – Improve clinic workflow                    – Implement a workflow-based system with user-friendly
  – Reduce participant time spent at clinic,     screens meeting the business process flows followed in
    Increase participant satisfaction, and       the clinics
    Increase staff time spent with             – Implement a system with automated features for
    participants                                 certification processing including growth chart plotting, ID/
  – Improve system process efficiencies          Verification of Certification (VOC) creation, appointment
                                                 scheduling, food package tailoring, and benefits issuance.
  – Support Electronic Benefits Transfer
    (EBT)                                      – Implement a system with data and process audits
  – Integrate with other health and human      – Implement a system that is EBT-enabled
    services systems for better participant    – Implement a system with integrations to Immunization,
    management and care                          Medicaid Eligibility, Maternal-Infant Health Program
                                                 (MIHP), Food Stamps, and other state systems.
Step 2 - Bid Information Sheet


(Pull up this form from the “Forms & Templates” link in TechTalk under
Contracts & Procurement Services)




                                                                         2
Step 3 - Requirements Gathering
     Gather requirements by whatever works best, on your timetable, and sometimes using
     methods in parallel
        Stakeholder analysis
           – Who are the people required for success – users, customers, vendors,
              auditors…?
           – What are their goals and objectives
           – What risks/costs do they identify
           – What are their suggestions, recommendations, solutions
        Interview of user groups
            – Identify their critical tasks – what are the stress points, when and what must
               be accurate
            – What are the data volumes
            – When do they perform tasks
            – What are the work processes, flows, procedures
                  Why do you ….?
                  Can you explain why you need to do ….?
        Observation of work
          – Watch someone work and take notes of the work flow
        Demonstration of work
          – More interactive, asking questions as work is performed to identify problem
             areas
        Review of existing documents
           –   Forms                               –   Screen shots
           –   Help desk tickets                   –   Self help applications/workarounds
           –   Letter files                        –   System documentation
           –   Customer                            –   Contracts
               suggestions/complaints

        Questionnaires – test the form for clarity
          – Identify biggest problems
          – What would user/manager/stakeholder like to see
        Brainstorming
           – Get out that white board/flipchart and note all ideas – even if they seem off
               base
           – Transcribe and let participants have a few days to study and then get back
               to prioritize what has been identified
        Focus groups – more structured
        Domain workshops – the subject matter experts
          – Team maps their business process with task description, data flow
             diagrams, activity diagrams, use case
          – Analyst turns into requirements
          – Need expert users and cross domain


                                                                                             3
   Design workshops
   – Users and IT developers cooperate to design
   Prototyping
   – Simplified version of solution
   Pilot
   – Trial with production data – usually used for COTS
   – Can organization change processes to adapt to COTS or will it be too costly to
       make changes
   Study similar organizations
   – How is another governmental entity handling problem
   – Have they developed business requirements
   – Especially helpful for federal programs with same tasks – WIC
   Ask vendors
   – Use the Horizon program to get information
Sometimes they are provided for you externally
      Statute
      Delivery Date
      Federal regulations
      Cost Drivers
      Sample – OFIS statute
          –    “The database application must do all of the following:
          –    Include a process for responding to transaction verification requests due to
               technical difficulties occurring with the database that prevent a DPP from
               accessing the database through the internet (P.A. 244 of 2005, Section 22(4)(a)).
          –    Provide accurate and secure receipt, transmission and storage of customer data
               (P.A. 244 of 2005, Section 22(4)(d) including:
          –    Compliance with any applicable provisions of the social security number privacy
               act, 2004 PA 452, MCL 445.81 to 445.87 (P.A. 244 of 2005, Section 22(4)(b)).
          –    Compliance with any applicable provisions of the identify theft protection act,
               2004 PA 452, MCL 445.61 to 445.77 (P.A. 244 of 2005, Section 22(4)(c)).


Step 4 - Statement of Work
      See tabs from “It’s a New Day”, the IT Procurement Handbook
      •       5 - SOW
      •       6 - Functional Requirements
      •       7 - Technical Requirements




                                                                                               4
The Four Components of a Business Requirement include:
  1.   General System Requirements
  2.   Functional Requirements
  3.   Quality Requirements
  4.   Technical Requirements



General System Requirements
       The general framework in which the solution/product must work:
             Capacity – number of employees needing to work concurrently; number of
             transactions to be handled, peak usage, file sizes
             Documentation requirements
                    End User
                    System administrator
                    System operation
                    System maintenance
             User Screens / Windows - not what they look like, but the information needed
             System Auditing
             Error Handling
             Online Help
             Backup and Recovery
             Disaster Recovery and Business Continuity
             Sample:
                –   Screens must comply with the American Disabilities Act (ADA) development
                    standards for user screens
       Maintenance and support
       Training
              On site – how many sessions, how many staff
              Web based
              Training materials
       Knowledge transfer
       Implementation and Implementation support
              If rolling out to multiple sites – will Vendor be required to have on site support
              Sample:
                –   The Vendor will provide training on upgrades and modifications of the system that
                    affect end-user functionality at no additional cost (e.g. classroom or online
                    training, training flier, tent card, and release features, etc.).




                                                                                                   5
Functional Requirements
     Functional Requirements identify what the product or system must do to enable
     performance of user tasks
            Tasks as they are done now
            Tasks as they are to be done in the future
     Functional Requirements can be the most labor intensive and detailed of all business
     requirements
            Sample:
            1.0 CERTIFICATION
            1.2 Determine Nutrition Risk of Applicant
            1.2.1 Maintain Applicant Nutrition and Health Characteristics
            1.2.1.1 Accept CPA identity and post it to applicable certification sessions
            1.2.1.2 Accept user entered Participant, Participant Health, and Breastfeeding data
            1.2.1.3 Update data stores
            1.2.1.4 Generate screen display of participant health data
     Functional Requirements may also specify more stringent requirements than general
     system requirements or general maintenance requirements
            Sample for a critical system:
            –   Vendor shall perform emergency fixes of the system to resolve problems having a
                significant impact on an end user’s ability to perform their job
                        Vendor shall respond within 30 minutes of notification of the problem.
                        Vendor shall provide a status update every 2 hours until the problem is
                        resolved.



Quality Requirements/Service Levels
     Availability – daily use by end users – system shall be accessible no less than 99.9%
     of the time between 7am and 6 pm on business days. Scheduled maintenance not
     included.
     Usability – fit for ease of use in real life tasks – can review prints on screen before
     printed on paper
     Reliability – system can perform without failures
     Correctness – system conforms to standards and requirements
     Performance – when system is at peak, what is the performance required – Online
     transactions – the time between user issuing command and complete screen
     appearance with system ready for new entry for this function, stated time in seconds
     for response
     Maintainability – ease of effort in finding and fixing a failure; will the added feature to
     COTS software be supported in future releases; must they be transferred at extra cost;
     maintained at extra cost
     Interoperability – ability of software to function on a variety of platforms and operating
     systems
     Portability – effort required to transfer system to another environment
     Expandability – amount of effort required to increase application’s capabilities and
     functionality
                                                                                                 6
Technical Requirements
    Technical requirements identify what the solution/product must run on, integrate with,
    and standards to be met:
          Hardware – PC, mainframe, client server, routers, load balancers etc.,
          Operating system – Windows, etc.
          Software, including database – Microsoft Office, Oracle (who holds the source
          code for application software)
          Development tools - .Net, Visual Basic, etc.
          Reporting tools – Crystal Reports, etc.
          Hosting environment and location – State Data Center, contractor site
          Communication channels - including telecom connectivity and capacity
          Network management
          Encryption
          Samples:
          –   Access to the database from the application must be through standard JDBC or
              ODBC drivers.
          –   System must support Internet Explorer 6.0 or above on Windows XP and Windows
              2000
          –   Tracking device will be a belt-worn device weighing no more than 1 lb. that collects
              GPS points while not in the charging stand.
    Security and Security Administration
           Sample:
          –   The system must provide read and write controls at the individual file or window
              level to protect sensitive data.
    Interfaces to retrieve and transfer data - internal and external interfaces
           Universal Product Code Scanners and UPC Data Exchange Interface
           Michigan Administration Information Network Interface
           Department of Human Services – BRIDGES Interface
           Regulatory agencies requiring data such as CDC, EPA
           Sample:
          –   Vendor must build all existing interfaces and new interfaces required to support the
              system. The current interfaces and expected future interfaces are:
                 1. Name of interface
                 2. Data transferred
                 3. Frequency




                                                                                                 7
How to Write a Business Requirement
    Use the language of the environment – your agency
    Organize the requirements in a natural pattern
          Of use
          Steps to achieve goal/single desired result
                 Including steps needing to prevent what could go wrong
    Is the requirement necessary?
            If use terms ”may, might, should, could, probably” you are not talking about a
            requirement
            “Shall” and “must” state requirements
    State a single desired result
           Not compound or multiple requirements in one sentence – break them into
           subcomponents
    Use simple, short and direct sentences
          Active tense
          Avoid jargon, if possible
          Spell out acronyms
    Avoid using “if, when, but, except, unless, although, always” when writing
    requirements
           Creates options, not a clear requirement that can be verified
           Used to state alternatives
                  Better to separate as distinct requirements
    A good requirement has a unique identifier and is:
          Verifiable – can be tested or checked for acceptance
          Attainable/feasible
          Unambiguous – all parties agree what they mean
          Complete – all necessary requirements are included
          Consistent – internally consistent with no conflict between
          Correct
          Traceable – you can determine where the requirement came from and where it
          is used
          Concise – avoid terms “usually, often, normally, generally”
          Not tied to a specific solution – give the what, not the how
                 Avoid names of components, materials, specific application language,
                 database fields




                                                                                             8
Review and Prioritization
     Build a good team of reviewers
     Encourage criticism
           No pride in authorship
     Review using agreed upon goals and objectives determined with Project Initiation
           Measure the requirement against
                 Will it help meet the goal/objective – it is a requirement
                 If it does not help meet the goal or objective, it is not a requirement
     Is the requirement understood by users and the project team
             If the document is too technical users may assume it is correct when it is not
             Hand walk users through – not just have them read
     Do not delete identified requirements – prioritize
           Is it required, essential, desirable
           State to be implemented later
           To be implemented when funds allocated


Keep in Mind
     Ground rules for requirements gathering
          No debate
          No criticism
          All ideas are valuable
          No decisions will be made here
     Specify what the product/application must do, not the solution
     Semantics
          IT and business may use same words and mean completely different things
     Time
            It takes time to develop requirements – budget for
            Allow time for feedback
     Change – be prepared
          Requirements will change
                  New needs
                  External factors – new regulations
          Priorities may change
          Have a process to manage
     Emotions
           Accept them, we have them and change seems to bring them all out
           There will be conflict
           Have a good facilitator comfortable with handling anger, defensiveness, silence,
           bull headedness




                                                                                              9