1.

Requirements

According to Websters dictionary:

a) something wanted or needed; necessity

b) something essential to the existence or occurrence of something else :condition

2. Software requirements

Requirements are descriptions of the services that a software system must provide and the constraints
under which it must operate.

For example, Ebay should provide new users with registration facility and existing users with
login. A constraint might be to implement the application using C# only. Time, cost (budget) and
scope are inherent constraints for every project (Read Triple constraints here:
https://programsuccess.wordpress.com/2011/05/02/scope-time-and-cost-managing-the-
triple-constraint/ )

2.1 Online Hospital Management System (OHMS) Exemplifying Requirements from a clients
perspective

Online Hospital Management System (OHMS) is an online system designed to facilitate patients, doctors,
lab attendants and receptionist. OHMS enables patients to log in and get appointment; submit case
history, earlier diagnosis reports and cancel or delay appointments. Doctors can get patients case
history, suggest therapies and medicines, cancel appointment, suggest tests and get emergency alerts.
Lab attendants will get patient details along with the suggested tests by the doctor. Lab reports will then
be sent to respective doctor. Receptionist will refer patients to OPD, schedule appointments, allot beds
and ward numbers to serious patients, maintain final bill and update patient bed/ward allotment after
discharge.

3. Types of software requirements

There can be many but we are concerned with only two here that are: Functional and Non-functional
requirements.

Functional requirements: Statements of services that the system should provide, how the
system should react to particular inputs and how the system should behave in particular
situations. For example, the requirements mentioned in above case study of OHMS are
functional requirements. They are translated into use cases and are mandatory requirements.

Non-functional requirements: Constraints on the services or functions offered by the system

such as timing constraints, constraints on the development process, standards, etc. They are, in
short, minimum acceptable performance for the system under development. For example, for
above mentioned case study, non-functional requirements may be: security, usability, reliability,
 performance/response time etc. These are optional requirements but its better to incorporate
NFR to improve software performance. They are also known as quality requirements.

Table1: Non-functional requirements and their measurement

Domain requirements: Requirements that come from the application domain of the system that
reflect the characteristics of that domain. They may be functional or non-functional
requirements in nature. If domain requirements are not satisfied system may be unworkable.
For example, security, reliability and OHMS should support the check-in and check-out for IPD
(In Patient) and OPD (Out-patient Department). Domain requirements come from
understanding domain knowledge.

4. Software Requirement Specification (SRS)

SRS is the artifact produced at the end of requirement gathering. SRS is agreed upon and signed off by
all the necessary stakeholders and, based on SRS the rest of the software development activities
(analysis, design, code, test and deployment) are performed.

5. Important concept for OOAD Validation and verification

Verification is performed at every stage/phase of the SDLC to ensure that you are going according to the
agreed specifications. It is done through document reviews, inspections and walkthroughs.

Validation is performed at the end to ensure that your end product is according to the customers
expectations that were recorded in SRS. It is done by executing the code.
It is a necessary concept because we too have to implement the functionality stated in case
studies/requirements document. Object oriented analysis should be according to requirements and,
object oriented design should be according to analysis.

Activity:

1. Identify functions, attributes and classes in above OHMS case study.

2. Improve OHMS case study; add more functionalities.