Requirement Discovery || Techniques For Requirements || Bcis Notes

Requirement Discovery

Requirements discovery is the process and techniques used by systems analysts to identify or extract system problems and solution requirements from the user community. In other words, Requirement Discovery is a stage in an engineering project where an analyst or developer tries to find out (discover) as much as they can about the requirements for the particular project. The term is mostly used in Software Development projects. Depending on the methodology used, Requirement Discovery can be a separate stage or an ongoing activity.

System requirements

System requirement is something that the information system must do or property that it must have. Also called a business requirement. System Requirements to be used efficiently, all computer software needs certain hardware components or other software resources to be present on a computer.

Functional Requirements 

A Functional Requirement is a description of the service that the software must offer. It describes a software system or its component. A function is nothing but inputs to the software system, its behavior, and outputs. For Examples,

  • The software automatically validates customers against the ABC Contact Management System.
  • The Sales system should allow users to record customer sales.

Non-Functional Requirements

A non-functional requirement is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviors. They are contrasted with functional requirements that define specific behavior or functions. The plan for implementing functional requirements is detailed in the system design. For Example,

  • Accessibility
  • Auditability and control
  • Availability (see service level agreement)
  • Backup
  • Capacity, current, and forecast
  • Certification
  • Compliance
  • Configuration management

Results of Incorrect Requirements

  • The system may cost more than projected.
  • The system may be delivered later than promised.
  • The system may not meet the users’ expectations
    and they may not use it.
  • Once in production, costs of maintaining and
    the enhancing system may be excessively high.
  • The system may be unreliable and prone to errors
    and downtime.
  • The reputation of IT staff is tarnished as failure will be
    perceived as a mistake by the team.

Criteria For System Requirements

  • Consistent – not conflicting or ambiguous.
  • Complete – describe all possible system inputs and
    responses.
  • Feasible – can be satisfied based on the available
    resources and constraints.
  • Required – truly needed and fulfill the purpose of
    the system.
  • Accurate – stated correctly.
  • Traceable – directly map to functions and features
    of the system.
  • Verifiable – defined so can be demonstrated during
    testing.

you may also like The Logical Design Phase 

Be the first to comment

Leave a Reply

Your email address will not be published.


*