-. System requirements should set out what the system should do rather than 
   how this is done. 
   -. Some  of the  problems that arise  during the  requirements engineering process  are a  
   result of failing  to make a clear separation between  these different levels of description.  
   -. The  term requirements definition to  mean the high-level  abstract description of what  
   the system should do : 
        (1) A requirements definition 
        (2) A requirements specification
        (3) A Software specification

   -.  The  requirements    engineering  process  should    normally   involve    writing  a                         
   requirements definition then expanding this into a requirements specification. 
   -. The software specification is an implementation-oriented document. 
   -. There   are several  reasons why   it is  virtually impossible   to  define   a complete    
   and consistent set of requirements to address a problem :
        (1) Large software systems are usually required to improve upon the status quo.
        (2) Large systems usually have a diverse user community.
        (3) The people who pay for a system and the users of a system are rarely the same 
           people.

  4.1 The requirements engineering process
        There are four principal stages in this process :
                (1) Feasibility study
                (2) Requirements analysis
                (3) Requirements definition
                (4) Requirements specification

   4.2 The software requirements document
        -. The software requirements document  is not a design document. It should set  out  
        what the system should do without specifying how it should be done.
        -. In   principle,  the   requirements set   out  in this   document ought     to   be  
        complete and  consistent. All system functions  should be specified  and requirements 
        should not conflict.
        -.  Heninger(1980) suggests  that  there  are   six  requirements which  a  software   
        requirements document should satisfy :
                +. It should be specify external system behaviour.
                +. It should specify contraints on the implementation.
                +. It should be easy to change.
                +. It should serve as a reference tool for system maintainers.
                +. It should record forethought about the life cycle of the syste.
                +. It should characterize acceptable responses to undesired events.
        -. The requirements  document may also includem either  in separate chapters in the 
        document or as appendicesm the following information :
                (1) Hardware
                (2) Database requirements
                (3) Index

   4.3 Requirements validation
        -. Requirements validation  is concerned with showing that the  requirements actually 
        define the system that the customer wants.
        -. There are several aspects of the requirements which must be checked :
                (1) Validity
                (2) Consistency
                (3) Completeness
                (4) Realism
        -.  Validation  should  not  be seen  as  a  process  to  be  carried  out agter  the    
        requirements document has been completed. 
        -. A requirements review  is a manual process which involves  multiple readers from 
        both client  and contractor  staff checking the  requirements document  for anomalies  
        and omissions. 
        -. Informal reviews simply involve contractors discussing requirements with clients.
        -. In  a formal requirements review,  the development team  should 'walk' the client   
        through the system requirements explaining the implecations of each requirements. 
        -. They might also check for :
                +. Verifiability
                +. Comprehensibility 
                +. Traceability
                +. Adaptability
        -. Requirements  reviews are  generally successfull in  detecting many errors  in the   
        requirements definition. 
 
   4.4 Requirements evolution
        -. From an evolution perspective, requirements fall into two classes :
                (1) Enduring requirements
                (2) Volatile requirements
        -. Enduring requirements can sometimes be derived from domain models.
        -. Volatile requirements fall into four classes. 
                +. Mutable requirements 
                +. Emergent requirements
                +. Comsequential requirements
                +. Compatibility requirements