Bài giảng Introduction to Software Engineering - Week 4: Requirement Engineering - Nguyễn Thị Minh Tuyền
Week 4:
Requirement Engineering
Nguyễn Thị Minh Tuyền
Adapted from sSlidoemsmoef rIavnille
Requirements Engineering
£ What is it?
£ Who does it?
£ Why is it important?
£ What are the steps?
£ What is the work product?
£ How do I ensure that I’ve done it right?
2
Topics covered
1. Functional and non-functional requirements
2. Requirements engineering processes
3. Requirements elicitation and analysis
4. Requirements specification
5. Requirements validation
6. Requirements management
3
Requirements engineering
£ The process of establishing the services that a
customer requires from a system and the
constraints under which it operates and is
developed.
£ The system descriptions of
the system services and constraints that are
generated during the requirements engineering
process.
4
What is a requirement?
£ It may range from
p a high-level abstract statement of a service or of a
system constraint, to
p a detailed mathematical functional specification.
£ Requirements may serve a dual function
p May be the basis for a bid for a contract - therefore must
be open to interpretation;
p May be the basis for the contract itself - therefore must
be defined in detail;
p Both these equirements.
5
Requirements abstraction (Davis)
“If a company wishes to let a contract for a large software
development project, it must define its needs in a sufficiently
abstract way that a solution is not pre-defined. The
requirements ml contractors
can bid for the contract, offering, perhaps, different ways of
meeting the client organization’s needs. Once a contract
has been awarded, the contractor must write a system
definition for the client in more detail so that the client
understands and can validate what the software will do.
Both of these documents may be called the requirements
document for the system.”
6
Types of requirement
£ User requirements
p Statements in natural language plus diagrams of the
services the system provides and its operational
constraints.
p Written for customers.
£ System requirements
p A structured document setting out detailed descriptions
of the system’s functions, services and operational
constraints.
p Defines what should be implemented so may be part of
a contract between client and contractor.
7
User and system requirements
User requirement definition
1. The Mentcare system shall generate monthly management reports
showing the cost of drugs prescribed by each clinic during that month.
System requirements specification
1.1 On the last working day of each month, a summary of the drugs
prescribed, their cosbe generated.
1.2 The system shall automatically generate the report for printing after
17:30 on the last working day of the month.
1.3 A report shall be created for each clinic and shall list the individual drug
names, the total number of prescriptions, the number of doses prescribed
and the total cost of the prescrbed drugs.
1.4 If drugs are available in different dose units (e.g. 10mg, 20mg, etc.)
separate reports shall be created for each dose unit.
1.5 Access to all cost reports shall be restricted to authorized users listed
on a management access control list.
8
Readers of different types of
requirements specification
Client managers
System end-users
Client engineers
Contractor managers
System architects
User
requirements
System end-users
Client engineers
System architects
Software developers
System
requirements
9
System stakeholders
£ Any person or organization who is affected by the
system in some way and so who has a legitimate
interest
£ Stakeholder types
p End users
p System managers
p System owners
p External stakeholders
10
Stakeholders in the Mentcare
system
£ Patients whose information is recorded in the system.
£ Doctors who are responsible for assessing and treating
patients.
£ Nurses who coordinate the consultations with doctors and
administer some treatments.
£ Medical receptionists who manage patients’ appointments.
£ IT staff who are responsible for installing and maintaining the
system.
£ A medical ethics manager who must ensure that the system
meets current ethical guidelines for patient care.
£ Health care managers who obtain management information
from the system.
£ Medical records staff who are responsible for ensuring that
system information can be maintained and preserved, and
11
Agile methods and requirements
£ Many agile methods argue that producing detailed system
requirements is a waste of time as requirements change so
quickly.
£ The requirements document is therefore always out of
date.
£ Agile methods usually use incremental requirements
engineering and may express requirements as ‘user
stories’
£ This is practical for business systems but problematic for
systems that ysis (e.g. critical
systems) or systems developed by several teams.
12
Topics covered
1. Functional and non-functional requirements
2. Requirements engineering processes
3. Requirements elicitation and analysis
4. Requirements specification
5. Requirements validation
6. Requirements management
13
Functional and non-functional requirements
£ Functional requirements
p Statements of services the system should provide, how the
system should react to particular inputs and how the system
should behave in particular situations.
p May state what the system should not do.
£ Non-functional requirements
p Constraints on the services or functions offered by the system
such as timing constraints, constraints on the development
process, standards, etc.
p Often apply to the system as a whole rather than individual
features or services.
£ Domain req
p Constraints on the system from the domain of operation
14
Functional requirements
£ Describe functionality or system services.
£ Depend on
p the type of software,
p expected users and
p the type of system where the software is used.
£ Functional user requirements may be high-level
statements of what the system should do.
£ Functional system requirements should describe
the system services in detail.
15
Functional requirements for the Mentcare
system
1. A user shall be able to search the appointments
lists for all clinics.
2. The system shall generate each day, for each
clinic, a list of patients who are expected to attend
appointments that day.
3. Each staff member using the system shall be
uniquely identified by his or her 8-digit employee
number.
16
Requirements imprecision
£ Problems arise when requirements are not
precisely stated.
£ Ambiguous requirements may be interpreted
in different ways by developers and users.
£ Example: rch’
p User intention: search for a patient name across
all appointments in all clinics;
p Developer interpretation: search for a patient
name in chooses clinic
then search.
17
Requirements completeness and
consistency
£ In principle, requirements should be both
complete and consistent.
£ Complete
p They should include descriptions of all facilities
required
£ Consistent
p There should be no conflicts or contradictions in
the descriptions of the system facilities.
£ In practice, it is impossible to produce a
complete and consistent requirements
document.
18
Non-functional requirements
£ These define system properties (e.g. reliability,
response time and storage requirements) and
constraints (e.g. I/O device capabilities, system
representations, etc.).
£ Non-functional requirements may be more critical
than functional requirements.
p If these are not met, the system may be useless.
19
Types of nonfunctional requirement
Non-functional
requirements
Product
requirements
Organizational
requirements
External
requirements
Efficiency
requirements
Dependability
requirements
Security
requirements
Regulatory
requirements
Ethical
requirements
Usability
requirements
Environmental
Operational
Development
quirements
Legislative
requirements
Performance
requirements
Space
requirements
Accounting
requirements
Safety/security
requirements
20
Tải về để xem bản đầy đủ
80 trang
18940
Free
Bạn đang xem 20 trang mẫu của tài liệu "Bài giảng Introduction to Software Engineering - Week 4: Requirement Engineering - Nguyễn Thị Minh Tuyền", để tải tài liệu gốc về máy hãy click vào nút Download ở trên
File đính kèm:
- bai_giang_introduction_to_software_engineering_week_4_requir.pdf
