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.
Voordelen van het kopen van samenvattingen bij Stuvia op een rij:
Verzekerd van kwaliteit door reviews
Stuvia-klanten hebben meer dan 700.000 samenvattingen beoordeeld. Zo weet je zeker dat je de beste documenten koopt!
Snel en makkelijk kopen
Je betaalt supersnel en eenmalig met iDeal, creditcard of Stuvia-tegoed voor de samenvatting. Zonder lidmaatschap.
Focus op de essentie
Samenvattingen worden geschreven voor en door anderen. Daarom zijn de samenvattingen altijd betrouwbaar en actueel. Zo kom je snel tot de kern!
Veelgestelde vragen
Wat krijg ik als ik dit document koop?
Je krijgt een PDF, die direct beschikbaar is na je aankoop. Het gekochte document is altijd, overal en oneindig toegankelijk via je profiel.
Tevredenheidsgarantie: hoe werkt dat?
Onze tevredenheidsgarantie zorgt ervoor dat je altijd een studiedocument vindt dat goed bij je past. Je vult een formulier in en onze klantenservice regelt de rest.
Van wie koop ik deze samenvatting?
Stuvia is een marktplaats, je koop dit document dus niet van ons, maar van verkoper BpoBpo. Stuvia faciliteert de betaling aan de verkoper.
Zit ik meteen vast aan een abonnement?
Nee, je koopt alleen deze samenvatting voor €4,30. Je zit daarna nergens aan vast.
