Topic 2: Requirement Analysis

• Requirement analysis in Software development is important as it helps to meet the needs of the clients and end-users and not just their wants.
• Requirement analysis in software development involves understanding the problem they need to solve, and the tasks they need to accomplish with the software.
• Software development must start with a quality set of software requirements, which are later planned, designed, implemented, and tested
• A requirement is a software capability needed by the user to solve a problem or to achieve an objective.
• All stakeholders in a project must achieve a common understating of what the product will be and do.
• Requirement analysis

  • Eliciting Requirements: the task of communicating with customers and users to determine what their requirements are.
  • Requirements Modelling: Requirements might be documented in various forms.
  • Analysing Requirements: determining whether the stated requirements are unclear, incomplete, ambiguous, or contradictory, and then resolving these issues.
  • Review and Retrospective: Team members reflect on what happened in the iteration
• There are 2 types of requirements. Functional requirements (capabilities/features that the system must have) and non-functional requirements (constraints that the new system must meet)
• Properties of a requirement:

  • Unambiguous: Documentation must be clear and everyone must be able to understand.
  • Consistent
  • Comprehensive: Steps must be clear and precise
  • Prioritised: Be realistic of what can you can do and prioritise the important things first
  • Verifiable: project must be able to be verified
• Steps of requirement analysis: 1. Gather detailed information

  • Talk to users of new system or similar systems
  • Read documentations on existing system
  • Develop expertise in business area of the system
  • Collect technical information (computers and stuff)
• Steps of required analysis: 2. Identify Functional requirements

  • System requirement that describes what the system must perform
  • Typically, it is needed to support business processes
• Steps of required analysis: 3. Identify non-functional requirements

  • Constraints or characteristics expected from the system.
  • Typically includes Performance, usability, reliability, security.
• Steps of required analysis: 4. Prioritise requirements

  • Manage users requests according to user needs, urgency, complexity, estimated efforts needed.
  • Balance between limitation of resources vs user needs.
  • Scope creep: the tendency for a function list to grow in a uncontrolled manner.
• Steps of required analysis: 5. Evaluate requirements

  • Evaluate requirements with user till an acceptable requirement model is developed.
  • Evaluate all possibilities in the design and implementation of system
  • Validate the accuracy and correctness of requirements
  • Process is iterative
• Techniques for requirement gathering:

  • Questioning, Observing, Researching, Modelling
  • Good questions initiate process
  • Questions center around three themes.
  • What are business processes?
  • How is the business process performed?
  • What information is required?
• Techniques for requirement Gathering - Interview users and other stakeholders:

  • Most widely used fact-finding technique
  • Types of questions involved: Mixture of open and close ended questions.
  • Pros
  • Effective way to understand business functions and business rules
  • Cons
  • Time-consuming and requires further rework on the interview information gathered.
  • When to use: Require in-depth information on new/existing system.
• Techniques for requirement gathering - Distribute and collect questionnaires.

  • Typically includes close-ended question and opinions questions.
  • Explanation of procedure or problem
  • Pros
  • Economical for large group which supports distributed geographical location
  • Cons
  • Hard to construct good questions and constraint to research further.
  • When to use: Input from large number of people who are geographically dispersed.
• Techniques for requirement Gathering - Review inputs, outputs, and documentation

  • 2 Sources of information
  • External to the organisation
  • Industry journals and magazines report the findings of "best practices" studies
  • Existing business documents and procedure descriptions within the organisation
  • Gets preliminary understanding of the processes
  • Serves as visual aids
  • Pros
  • Allow analysts to get an understanding of the organisation before meeting the users.
  • Cons
  • Documents may not match up to actual operations or outdated.
  • When to use: in the initial stages when an analyst is unfamiliar
• Techniques for requirement Gathering - Observe and Document Business Processes

  • Diagram all information gathered into workflows
  • create activity diagrams (Identify activities, relationships between activities, personnel responsible for the activities)
  • Pros
  • First-hand experience in system operations allowing validation of information and business performance.
  • Cons
  • Can be intrusive with information confidentiality issue
  • When to use: gather quantitative data about business and validation of conflicting information provided.
• Techniques for requirement Gathering - Building Effective Prototypes

  • It is an initial, look alike model with limited features of a real production system
  • Discovery prototype
  • model created to verify concept and discarded
  • Evolving prototype
  • working model that grows and may become part of system
  • Mock-up
  • example of final product for viewing only, not executable
• Techniques for requirement Gathering - Building Effective Prototypes

  • Pros
  • Time and cost saving
  • Inaccurate user requirements can be discovered earlier with greater user involvement
  • Cons
  • Too much time spent on prototype rather than analysis.
  • When to use: Projects with high interactivity with users.
• Techniques for requirement Gathering - Research Vendor Solution

  • Pros
  • Provides a platform for learning from past experiences
  • Cheaper and less risky to buy a solution rather than to build it
  • Cons
  • Features to support business is general and a lot of companies find out that they only support half the functions that were needed after purchase
  • When to use: Features to support business is general and nothing too specific.