Requirements engineering (RE) refers to the process of defining, documenting, and

maintaining requirements in the engineering design process. Requirement

engineering provides the appropriate mechanism to understand what the customer
desires, analyzing the need, and assessing feasibility, negotiating a reasonable
solution, specifying the solution clearly, validating the specifications and managing
the requirements as they are transformed into a working system.

Software Requirements: Largely software requirements must be categorized into

two categories:

Functional Requirements: Functional requirements define a function that a

system or system element must be qualified to perform and must be documented in
different forms. The functional requirements are describing the behavior of the
system as it correlates to the system's functionality.

Non-functional Requirements: This can be the necessities that specify the criteria
that can be used to decide the operation instead of specific behaviors of the system.

Non-functional requirements are divided into two main categories:

Execution qualities like security and usability, which are observable at run time.

Evolution qualities like testability, maintainability, extensibility, and scalability

that embodied in the static structure of the software system.
Requirements imprecision

A major contributor to project failure is the failure to spend the time at the
beginning of the project to clearly define the product requirements before
beginning product development i.e., gathering imprecise requirements.

Example: Consider the term ‘search’ in requirement 1

User intention – search for a patient name across all appointments in all clinics;

Developer explanation – search for a patient name in an individual clinic. User

chooses clinic then search.

Requirements document

The software requirements document is the official statement of what is required of

the system developers. Should include both a definition of user requirements and a
specification of the system requirements. It is NOT a design document. As far as
possible, it should set of WHAT the system should do rather than HOW it should
do it.

Structured Specification of requirements

It’s a way of writing the requirements in a more formal and structured form.

It uses standard templates to specify the requirements. The specification can be

structured around the functions or events performed by the system.
Requirements checking

Validity; Does the system provide the functions which best support the customer’s
needs?

Consistency; Are there any requirements conflicts?

Completeness; Are all functions required by the customer included?

Realism; Can the requirements be implemented given available budget and

technology?

Verifiability; Can the requirements be checked?