This document contains comprehensive notes from Lecture 1 of the CO2401 course on Software Development. The lecture focuses on the critical process of understanding and defining system requirements, a foundational aspect of successful software development.
Understanding Requirements
1. What Are Requirements?
o A requirement is a condition or capability that a system must
conform to or fulfil.
o It specifies what should be implemented in the system.
o Requirements can be viewed differently depending on the
stakeholder:
Business Analyst: User requirements.
Architect: Influences on the system’s design.
Developers: Drives design choices.
2. Whose Requirement?
o A system's property that provides value to its stakeholder. To
understand requirements, one must understand the stakeholders,
which include:
Users
Developers
Sponsors
Types of Requirements
1. User Requirements
o Statements in natural language plus diagrams of the services the
system provides and its operational constraints.
o Written for customers.
2. System Requirements
o A structured document detailing the system’s functions, services,
and operational constraints.
o Defines what should be implemented, often part of a contract
between client and contractor.
, 3. Examples
o User Requirement: The system shall generate monthly
management reports showing the cost of drugs prescribed by each
clinic.
o System Requirement: The system shall generate the report for
printing after 17:30 on the last working day of the month.
Agile Methods and Requirements
1. Overview
o Agile methods argue that producing detailed system requirements
may be unnecessary as requirements change rapidly.
o Incremental requirements engineering is used, often expressed as
"user stories."
2. Agile Methods
o Scrum, Kanban, and Extreme Programming (XP) are common
agile methods.
o While practical for business systems, agile methods can be
problematic for critical systems requiring pre-delivery analysis or
those developed by multiple teams.
Functional and Non-Functional Requirements
1. Functional Requirements
o Describe what the system should do, including system functions,
inputs, outputs, and behaviour in specific situations.
o Examples:
A user shall be able to search the appointments list for all
clinics.
Each staff member using the system shall be uniquely
identified by their 8-digit employee number.
2. Non-Functional Requirements
o Constraints on the services or functions offered by the system, such
as reliability, response time, and storage requirements.
o These requirements are often more critical than functional
requirements. If unmet, the system may be useless.
o Examples:
Product requirement: The system shall implement patient
privacy provisions.
The benefits of buying summaries with Stuvia:
Guaranteed quality through customer reviews
Stuvia customers have reviewed more than 700,000 summaries. This how you know that you are buying the best documents.
Quick and easy check-out
You can quickly pay through credit card or Stuvia-credit for the summaries. There is no membership needed.
Focus on what matters
Your fellow students write the study notes themselves, which is why the documents are always reliable and up-to-date. This ensures you quickly get to the core!
Frequently asked questions
What do I get when I buy this document?
You get a PDF, available immediately after your purchase. The purchased document is accessible anytime, anywhere and indefinitely through your profile.
Satisfaction guarantee: how does it work?
Our satisfaction guarantee ensures that you always find a study document that suits you well. You fill out a form, and our customer service team takes care of the rest.
Who am I buying these notes from?
Stuvia is a marketplace, so you are not buying this document from us, but from seller BpoBpo. Stuvia facilitates payment to the seller.
Will I be stuck with a subscription?
No, you only buy these notes for $4.52. You're not tied to anything after your purchase.
