Requirement Elicitation

Requirement Elicitation

1. Functional Requirements

   • How the system should react/behave to particular inputs/situations

2. Non-Functional Requirements

   • Constraints on the services offered by the system
   • Constraints on the services offered by the system
   • Often refer to whole system and are more critical

3. Steps in requirement elictation

   • 1. Application domain understanding
     • Discussing with the client what they want
   • 2. Requirements collection and classification
     • Sorting requirements into coherent groups
   • 3. Conflict resolution
     • different demands from user, system safety vs availability, data security vs accessability
   • 5. Prioritsation
   • 4. Requirements checking
     • verifiability
       • Have measures been specified against which success can be judged
     • consistency
       • Are there any inconsistencies or conflicts among requirements?
     • realism
       • Is it feasible to rsatisfy requirements given limitations in technology & budget?
     • Validity
       • Do all perceived requirements solve real problems?
     • for Completeness
       • Have we captured all requirements?

4. Different ways to represeent requirements

   • Diagrams
     • Formality and rigour - Strict notations in symbols have particular meaning and enforce precise descriptions diagramming is a design excersise - better understanding of the problem system views at different levels of abstraction - diagrams can show high-level views of a system as well as detailed views effective representation of architecture and behaviour: Diagrams can show both structure/composition and behaviour  
     • View Points
       • View Points provide a multi-prespective analysis of requirements from different classes of users that have a different role in the usage of a system
     • Use case Diagrams
       • Use case diagrimes identify use cases and use cases describe detailed scenarios of operation showing main and alternative flow of events
     • State Machines
       • State Machines can show how the state of a system or an object within changes in response to events generated by users and the enviroment. they can capture requirements as well as describe the design of a system.
   • pseudocode
     • Pseudocode uses a combination of concepts of a programming language and free text to describe things rather than strictly defined program entitites
   • natural language
     • Normal language, people can understand and is expressive.. but can be imprecise without long sentences & paragraphs which make documents hard to read. Relationships are difficult to record and see in such documents.