Random Thoughts‎ > ‎

About the requirements analysis ...

posted Mar 12, 2011, 1:25 PM by Alar Raabe   [ updated Mar 12, 2011, 1:41 PM ]
  1. Requirements Analysis and Specification
    1. Purpose – to understand what is required and to communicate that understanding to other parties.
    2. Team
      1. Lead analyst – driving the analysis and requirements process (knowledgeable in analysis and requirements specification techniques).
      2. Domain Experts – bringing the domain knowledge to the analysis and specification process.
      3. Technical Experts – bringing the technical knowledge to the specification process (assuring that the solution which satisfies the stated requirements is feasible).
    3. Process
      1. Iterative process, where analysis and specification tasks alternate until the satisfactory requirements specification is produced.
    4. Tasks
      1. Requirements Analysis
        1. Purpose – to understand what is required.
        2. Methods
          1. Study of documents – to collect formal information.
          2. Interview of involved parties – to collect informal information.
          3. Workshops – to assure, that all the relevant viewpoints are taken into account.
          4. Modeling and prototyping – to assure, that all the relevant questions are asked.
      2. Requirements Specification
        1. Purpose – to communicate what is required to other parties (developers, testers, ...).
        2. Methods
          1. Writing specification documents – to describe the requirements.
          2. Modeling and prototyping – to assure, that requirements are
            1. unambiguous – all parties understand the same thing,
            2. complete – nothing that is necessary has been left out,
            3. correct – there are no errors,
            4. consistent – there are no contradictions,
            5. verifiable – result can be tested against the requirements,
            6. feasible – result can be achieved,
            7. prioritized – to allow scoping and risk management.
          3. Workshops – to assure, that specifications are correct.
    5. Results
      1. Requirements Specification Documents.
      2. Models and prototypes.
  2. Important parts of the business software system (should be defined in the results of requirements specification)
    1. Overview – what is the overall purpose and the context (environment) of the system and what are the non-functional requirements (performance, response time, etc.).
    2. Data – what information the system maintains (business entities and relationships, their life-cycle and corresponding business rules).
    3. Roles – who are the users and what rights they have to perform functions that system provides.
    4. Functions – what functions system provides to the users (business processes, business transactions and corresponding business rules).
    5. User Interface – what data is presented to and can be entered by the user and what functions are accessible to the user, how the system responds to the user actions.
    6. Printouts and reports – what data is collected from the system and how it is presented to the user.
    7. External Interfaces – what are the connection points of the system with its environment.

Because every requirement has a price attached (in terms of time and money), they should be handled with care and precision (as money is handled).
Comments