To define a set of requirements that can be validated once the software is built

What is a model?Ans:a model is a simplification of reality

Why do we model?-we build models so that we can better understand the system we are developing.-we build models of complex systems because we cannot comprehend such a system in its entirety.-four aims to achieve:- 1. help us to visualize a system. 2. permit us to specify the structure/behavior of a system. 3. give us a template that guides us in constructing systems. 4.document the decisions we have made.

Use Case Diagram for Point of Sale

Traceability Tables

Features traceability table: Shows how requirements relate to important customer observable system/product features.Source traceability table: Identifies the source of each requirement.Dependency traceability table: Indicates how requirements are related to one another.Subsystem traceability table: Categorizes requirements by the subsystem(s) that they govern.Interface traceability table: Shows how requirements related to both internal and external system interfaces.

These define system properties and constraints e.g. reliability, response time and storage requirements. Constraints are I/O device capability, system representations, etc.i.e. Deactivate or delete record after 24 hrs

Process requirements may also be specified mandating a particular programming language or development method.

Non-functional requirements may be more critical than functional requirements. If these are not met, the system may be useless.

Types of Nonfunctional requirement

Product requirement: ExamplesThe MHC-PMS shall be available to all clinics during normal working hours (Mon–Fri, 0830–17.30). Downtime within normal working hours shall not exceed five seconds in any one day.

Organizational requirement: ExamplesUsers of the MHC-PMS system shall authenticate themselves using their health authority identity card.

User requirementsStatements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers.

System requirementsA structured document setting out detailed descriptions of the system’s functions, services and operational constraints. Defines what should be implemented so may be part of a contract between client and contractor.

Functional requirementsStatements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations.

May state what the system should not do.

Non-functional requirementsConstraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc.

Often apply to the system as a whole rather than individual features or services.