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