requirements engineering process lecture 4. adv software engg, mscs 19, by asst prof athar mohsin,...
TRANSCRIPT
REQUIREMENTS ENGINEERING PROCESS
Lecture 4
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST 2
Requirements • A requirement is defined as:
– A condition or capability needed by a user to solve a problem or achieve an objective;
• A condition or a capability that must be met or possessed by a system … to satisfy a contract, standard, specification, or other formally imposed document …” IEEE 830-1993
• The primary measure of success of a software system is the degree to which it meets the purpose for which it was intended. – Broadly speaking, software systems requirements
engineering (RE) is the process of discovering that purpose, by identifying stakeholders and their needs, and documenting these in a form that is amenable to analysis, communication, and subsequent implementation.
» Bashar Nuseibeh
Requirements Engineering• The process of establishing the services that the customer
requires from a system and the constraints under which it operates and is developed.– The requirements themselves are the descriptions of the system
services and constraints that are generated during the requirements engineering process.
• Requirements Type:– User requirements
• Statements in natural language plus diagrams of the services the system provides and its operational constraints.
• Written for customers.
– System requirements• A 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.
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST 3
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST 4
Challenges to Requirements • There are a number of inherent difficulties in RE process:
– Stakeholders may be numerous and distributed. – Stakholder’s goals may vary and conflicting
• Depending on their perspectives of the environment in which they work and the tasks they wish to accomplish.
– Stakeholder’s goals may not be explicit or may be difficult to articulate:
• satisfaction of these goals may be constrained by a variety of factors outside their control.
– Limitation of natural language• Ambiguity, consistency, understandability
– Writing vs reading – Verity of methods– Controlling/ managing/ tracing changes – validation
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST 5
Challenges to Requirements• So Many “Requirements”…
– A goal is an objective or concern used to discover and evaluate functional and non-functional requirements.
• A goal is not yet a requirement…– A functional requirement is a requirement defining functions of the
system under development• Describes what the system should do
– A non-functional requirement is a requirement characterizing a system property such as expected performance, robustness, usability, maintainability, etc.
• Constraints that must be adhered to during development – A user requirement is a desired goal or function that a user and other
stakeholders expect the system to achieve• Does not become necessarily a system requirement
– A domain requirement is a requirement derived from the application domain
• Can be functional or non-functional– Product Requirement– Process requirement– Security Requirements
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST 6
Challenges to Requirements
• Elicitation Risks and Challenges– Problems of scope
• System boundaries inadequately defined or defined too soon
• Unnecessary technical details
– Problems of understanding• Stakeholder not sure of what is needed
• Stakeholder has trouble communicating needs
• Stakeholder does not understand capabilities and limitation of computing environment
• Stakeholder does not have full understanding of domain
• Stakeholders state conflicting requirements
– Problems of volatility• Stakeholders will not commit to a set of written requirements
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST 7
Challenges to Requirements
• Elicitation Risks and Challenges– Other typical issues
• Experts seldom available• Finding an adequate level of precision/detail• Common vocabulary often missing• Sometimes hidden• Sometimes too obvious, implicit, ordinary…
– Participants often lack motivation and resist to change
• We need much efforts and discussion to come up with a common agreement and understanding
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST 8
Software Requirement- SWEBOK
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST 9
Requirements Engineering • “Requirements engineering is the branch of software
engineering concerned with the “REAL-WORLD GOALS” for, functions of, and constraints on software systems. It is also concerned with the relationship of these factors to “PRECISE SPECIFICATIONS” of software behavior, and to their EVOLUTION OVER TIME AND ACROSS SOFTWARE FAMILIES.”– Real world Goals: Motivate the development of a software
system.• Represent the ‘why’ and ‘what’ of a system.
– Precise Specification: Provide the basis for:• Analyzing requirements, • Validating (what stakeholders want),• Defining what designers have to build, and • Verifying that they have done so correctly upon delivery
– Evolution over Time: Emphasizing the reality of a changing world and the need to reuse partial specifications,
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST 10
Software requirements engineering • Process of determining what is to be produced in a
software system• An important aspect of any software project, and is
a general term used to encompass all the activities related to requirements. – The four specific steps in software requirements
engineering are: • Requirements Elicitation • Requirements Analysis • Requirements Specification • Requirements Validation
Seems to be separate tasks but these four processes cannot be strictly separated and performed sequentially and repeatedly
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST 11
RE Activities• Requirements elicitation
– Requirements discovered through consultation with stakeholders
• Requirements analysis and negotiation– Requirements are analyzed and conflicts resolved
through negotiation
• Requirements specification– A precise requirements document is produced
• Requirements validation– The requirements document is checked for consistency
and completeness
• Requirements management– Needs and contexts evolve, and so do requirements!
Acknowledgement to the work of Karl Wiegers, Software Requirements
Acknowledgement to the work of Karl Wiegers, Software Requirements
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST 12
•(Martin & Leffinwell)
Distribution of Effort to Fix Defects
Code7% Other
10%
Design27%
Requirements56%
Code1%
Other4%
Design13%Requirements
82%
Distribution of Defects
Why Focus on Requirements
•NIST (National Institute of Standards and Technology's)–70 % of the defects are introduced in the specification
phase –30 % are introduced later in the technical solution process. –Only 5 % of the specification inadequacies are corrected in
the specification phase –95 % are detected later in the project or after delivery
where the cost for correction in average is 22 times higher compared to a correction directly in the specification effort.
• The NIST report concludes that extensive testing is essential, however testing detects the dominating specification errors late in the process.
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST 13
Standish CHAOS Report -2010 – “This year’s results show a marked decrease in project
success rates, with 32% of all projects succeeding which are delivered on time, on budget, with required features and functions”
– Jim Johnson, chairman of The Standish Group says:• “44% were challenged which are late, over budget, and/or with
less than the required features and functions and 24% failed which are cancelled prior to completion or delivered and never used.”
– Five of the eight main factors for project failure deal with requirements:
• incomplete requirements,• low customer involvement, • unrealistic expectations, • changes in the requirements,• and useless requirements.
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST 14
Time
Why?
What?
How?
Who?When?
If-Then
Does It?
Where?
Project Management Process
Quality Management Process
Component & Configuration Management Process
Risk Management Process
Identify Business Needs and Goals
Derive User & Functional Requirements
Design Solutions
TIME
RE Process and Related Activities
• Whether viewed at the systems level or the software level, RE is a multi-disciplinary, human-centred process. – The tools and techniques used in RE draw upon a variety of
disciplines, and the requirements engineer may be expected to master skills from a number of different disciplines.
• RE must span the gap between the informal world of stakeholder needs, and the formal world of software behaviour, the key question over the use of formal methods is not whether to formalise, but when to formalise
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST 15
Why• “If you don’t get the requirements right, it doesn’t matter how
well you do anything else.” One can end up doing a perfect job of building the wrong product.
» Karl Wiegers (2004)
• Issues that can have a negative impact– Incomplete requirements:
• A software product that does not meet all of the customer and user’s needs.
– Lack of user involvement: • if practitioners miss a stakeholder group
– Requirements mix: • changes in the requirements after initially agreement, missing, poorly
written or ambiguous requirements– Wasted resources:
• Requirements errors results in 70-85 percent of the rework– Gold plating:
• Developer adds functionality that was not in the requirements specification
– Inaccurate estimates: • Requirement defines the scope, scope help is schedule and cost
estimation
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST 16
“What”- Part of the Requirements
• Requirements must be determined and agreed to by the customers, users, and suppliers of a software product before the software can be built.
• The requirements define the “what” of a software product:– What the software must do to add value for its stakeholders.
• These functional requirements define the capabilities of the software product.
– What the software must be to add value for its stakeholders. • These nonfunctional requirements define the characteristics, properties,
or qualities that the software product must possess.
• They define how well the product performs its functions.
– What limitations there are on the choices that developers have when implementing the software.
• The external interface definitions and other constraints define these limitations.
Why the Software is being developed
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST 17
Who• Stakeholders who affect or are affected by the
software product and therefore have some level of influence over the requirements for that software product.– The RE process consider all of the various stakeholder’s
interest in context with one another.– Stakeholders
• Acquirers– Purchasers & end users
• Suppliers– Organization & Developers (requirement Analyst, designer,
Developers, Testers & technical writer
• Others– Legal or contract management, Government or regulator agencies &
Society at large
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST 18
Who• The first step in identifying the stakeholders is to
make sure that one considers all of the potential stakeholders.
• The following checklist can help in identifying potential stakeholders:– What types of people will use the software product?– What business activities are supported by the software
product and who performs, or manages those activities?– Whose job will be impacted by the introduction of the new
software product?– Who will receive the reports, outputs, or other information
from the software product?– Who will pay for the software product?
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST 19
Software Requirement- SWEBOK• Requirements Process
– Process Actors• Stakeholders
• Process Support and Management
– make the link between the process activities and the issues of cost, human resources, training, and tools.
• Requirements Sources– Goals.
• (sometimes called ‘business concern’ or ‘critical success factor’)
refers to the overall, high-level objectives of the software.– Domain knowledge.
– Stakeholders
– The operational environment.
– The organizational environment.
– Similar System
– Documents / regulation / SOPs
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST 20
How• Software requirements engineering is a disciplined, process-
oriented approach to the definition, documentation, and maintenance of software requirements throughout the software development life cycle.– software requirements engineering is made up of two major processes:
requirements development and requirements management.
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST 21
How part of Requirements • Requirements Engineering: A Roadmap, Bashar Nuseibeh
– The context in which RE takes place is usually human activity system and the problem owner are people.
– Techniques for eliciting and modeling, drawn on cognitive and social sciences:
• Cognitive Psychology– Provides an understanding of the difficulties people may have in describing
their needs» domain experts often have large amounts of knowledge their answers to
questions posed by requirements analysts may not match their behaviour.
• Anthropology– Provides a methodological approach to observing human activities that helps
to develop a richer understanding
• Sociology– Provides an understanding of the political and cultural changes caused by
computerization.
• Linguistics– To avoid ambiguity and to improve understandability.
Eliciting Requirements• Requirements to Elicit
– Boundaries• Identify the high level boundaries of
the system• Stakeholders and Use Cases
depend on boundaries
– Goals• Denote the OBJECTIVES a system
must meet.• Eliciting High level goals early in
development– High level goals (business goals)
refined into lower level goals (technical goals) eventually operationalised in a system
– Tasks• When it is difficult to articulate user
requirements– Observe, case studies, scenarios
• Elicitation Techniques– Traditional Techniques
• Questionnaires and Surveys• Interviews• Analysis of existing
documentation
– Group Elicitation• Group brainstorming
sessions• RAD (Rapid Application
Development)• JAD (Joint Application
Design)
– Prototyping• Where there is great deal of
uncertainty• Early feedback from
stakeholders is needed
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST 22
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST 23
Sources of Requirements• Various stakeholders
– Clients, customers, users (past and future), managers, domain experts, developers, marketing and QA people, lawyers, auditors, anyone who can bring added value!
• Pre-existing systems– Not necessarily software systems
• Pre-existing documentation• Competing systems• Documentation about interfacing systems• Standards, policies, collective agreements,
legislation
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST 24
Comparison of some techniquesTechnique Good for Kind of data Plus Minus
Questionnaires Answering specific questions
Quantitative and qualitative data
Can reach many people with low
resource
The design is crucial. Response rate may be low.
Responses may not be what you want
Interviews Exploring issues Some quantitative but mostly
qualitative data
Interviewer can guide interviewee.
Encourages contact between developers
and users
Time consuming. Artificial
environment may intimidate
interviewee
Focus groups and workshops
Collecting multiple viewpoints
Some quantitative but mostly
qualitative data
Highlights areas of consensus and
conflict. Encourages contact between developers and
users
Possibility of dominant characters
Naturalistic observation
Understanding context of user
activity
Qualitative Observing actual work gives insight
that other techniques cannot
give
Very time consuming. Huge amounts of data
Studying documentation
Learning about procedures,
regulations, and standards
Quantitative No time commitment from
users required
Day-to-day work will differ from
documented procedures
Acknowledgment: Preece, Rogers, and Sharp “Interaction Design: Beyond human-computer interaction”, p214
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST 25
Software Requirement- SWEBOK• Product Requirements
– Requirements on software to be developed• The software shall verify that a student meets all prerequisites
before he or she registers for a course
• Process Requirements– A constraint on the development of the software
• The software shall be written in C#.
– Imposed directly by the development organization, their customer, or a third party such as a safety regulator
• Functional Requirements
– Describe the functions that the software is to execute – AKA Capabilities
• Non-Functional Requirements
– The ones that act to constrain the solution AKA Constraints
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST 26
Software Requirement- SWEBOK• Emergent Properties
– Requirements which cannot be addressed by a single component, but which depend for their satisfaction on how all the software components interoperate.
• Quantifiable Requirements– To avoid vague and unverifiable requirements which
depend for their interpretation on subjective judgment• The software shall be reliable’• ‘The software shall be user-friendly’
• System Requirements– An interacting combination of elements to accomplish a
defined objective.
• Software requirements are derived from system requirements.
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST 27
Functional Requirements – What inputs the system should accept– What outputs the system should produce– What data the system should store that other
systems might use– What computations the system should perform– The timing and synchronization of the above – Examples:
• The user shall be able to search either all of the initial set of databases or select a subset from it.
• The system shall provide appropriate viewers for the user to read documents in the document store.
• A user shall be able to search the appointments lists for all clinics.
• The system shall generate each day, for each clinic, a list of patients who are expected to attend appointments that day.
• Each staff member using the system shall be uniquely identified by his or her 8-digit employee number.
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST 28
Non-functional classifications• Product requirements
– Requirements which specify that the delivered product must behave in a particular way • e.g. execution speed, reliability, etc.
– The user interface for LIBSYS shall be implemented as simple HTML without frames or Java applets
• Organisational requirements– Requirements which are a consequence of organisational policies
and procedures • e.g. process standards used, implementation requirements, etc.
– The system development process and deliverable documents shall conform to the process and deliverables defined in organization’s mission statement
• External requirements– Requirements which arise from factors which are external to the
system and its development process• e.g. interoperability requirements, legislative requirements, etc.
– The system shall not disclose any personal information about customers apart from their name and reference number to the operators of the system.
Performancerequirements
Spacerequirements
Usabilityrequirements
Efficiencyrequirements
Reliabilityrequirements
Portabilityrequirements
Interoperabilityrequirements
Ethicalrequirements
Legislativerequirements
Implementationrequirements
Standardsrequirements
Deliveryrequirements
Safetyrequirements
Privacyrequirements
Productrequirements
Organisationalrequirements
Externalrequirements
Non-functionalrequirements
Metrics for specifying nonfunctional requirements
Property Measure
Speed Processed transactions/secondUser/event response time/ Screen refresh time
Size MbytesNumber of ROM chips
Ease of use Training timeNumber of help frames
Reliability Mean time to failure / AvailabilityProbability of unavailabilityRate of failure occurrence
Robustness Time to restart after failurePercentage of events causing failureProbability of data corruption on failure
Portability Percentage of target dependent statementsNumber of target systems
Domain requirements• The system’s operational domain imposes requirements on
the system.– For example, a train control system has to take into account the
braking characteristics in different weather conditions.
• Domain requirements be new functional requirements, constraints on existing requirements or define specific computations.
• If domain requirements are not satisfied, the system may be unworkable.
• Problems– Understandability
• Requirements are expressed in the language of the application domain;• This is often not understood by software engineers developing the system.
– Implicitness• Domain specialists understand the area so well that they do not think of making
the domain requirements explicit.
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST 30
Requirements imprecision• Problems arise when requirements are not precisely
stated.– Ambiguous requirements may be interpreted in different
ways by developers and users.
• Consider the term ‘search’ in following requirement– A user shall be able to search the appointments lists for
all clinics.• User intention:
– search for a patient name across all appointments in all clinics;
• Developer interpretation:– search for a patient name in an individual clinic. User chooses
clinic then search.
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST 31
Requirements completeness and consistency
• In principle, requirements should be both complete and consistent.– Complete
• They should include descriptions of all facilities required.
– Consistent• 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.
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST 32
The software requirements document• The software requirements document is the official
statement of what is required of the system developers.– Should include both a definition of user requirements and
a specification of the system requirements.– It is NOT a design document. – As far as possible, it should set of WHAT the system
should do rather than HOW it should do it.
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST 33
Requirements specification• The process of writing the user and system
requirements in a requirements document.– User requirements have to be understandable by end-
users and customers who do not have a technical background.
– System requirements are more detailed requirements and may include more technical information.
• The requirements may be part of a contract for the system development– It is therefore important that these are as complete as
possible.
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST 34
Ways of writing a system requirements specification
Notation Description
Natural language The requirements are written using numbered sentences in natural language. Each sentence should express one requirement.
Structured natural language
The requirements are written in natural language on a standard form or template. Each field provides information about an aspect of the requirement.
Design description languages
This approach uses a language like a programming language, but with more abstract features to specify the requirements by defining an operational model of the system. This approach is now rarely used although it can be useful for interface specifications.
Graphical notations Graphical models, supplemented by text annotations, are used to define the functional requirements for the system; UML use case and sequence diagrams are commonly used.
Mathematical specifications
These notations are based on mathematical concepts such as finite-state machines or sets. Although these unambiguous specifications can reduce the ambiguity in a requirements document, most customers don’t understand a formal specification. They cannot check that it represents what they want and are reluctant to accept it as a system contract
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST 36
Structure of a Good Requirement
“The system shall allow the Internet user to accesshis current account balance in less than 5 seconds.”
Defines a positive end result Performance criteria
Defines a subject Shall or should verb
•This requirement sentence identifies a specific subject and end result that is wanted within a specified time that is measurable.
– The challenge is to seek out the subject, end result, and success measure in every requirement you define!
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST 37
“The Internet user quickly sees the balance of heraccount on the laptop screen .”
Cannot write a requirement on the user
Vague quality criterion What versus how
No identifier for the verb
Example of a Bad Requirement
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST 38
Standard for Writing a Requirement–Each requirement must first form a complete sentence
• Not a bullet list of buzzwords–Each requirement contains a subject and predicate
• Subject: a user type or the system under discussion• Predicate: a condition, action, or intended result.
–Consistent use of the verb:• “shall,” “will”, or “must” to show mandatory nature• “should” or “may” to show optionality• Usually, shall and should are used.
–A requirement contains a success criterion or other measurable indication of the quality.
–A requirement describes what must be done, rather than how.
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST 39
Writing errors to Avoid
•Never describe how the system is going to achieve something (over-specification), always describe what the system is supposed to do
–Refrain from designing the system• Danger signs: using names of components, materials,
software objects, fields & records in the user or system requirements
–Designing the system too early may possibly increase system costs
–Do no mix different kinds of requirements (e.g., requirements for users, system, and how the system should be designed, tested, or installed)
–Do not mix different requirements levels (e.g., the system and subsystems)• Danger signs: high level requirements mixed in with
database design, software terms, or very technical terms
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST 40
Writing errors to Avoid
•“What versus how” test
The system shall use Microsoft Outlook to send an email to the customer with the purchase confirmation.
The system shall inform the customer that the purchase is confirmed.
X
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST 41
Writing errors to Avoid•Never build in let-out or escape clauses
–Requirements with let-outs or escapes are dangerous because of problems that arise in testing
–Danger signs: if, but, when, except, unless, although• These terms may however be useful when the
description of a general case with exceptions is much clearer and complete that an enumeration of specific cases
•Avoid ambiguity–Write as clearly and explicitly as possible–Ambiguities can be caused by:
• The word or to create a compound requirement• Poor definition (giving only examples or special cases)• The words etc, …and so on (imprecise definition)
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST 42
Writing errors to Avoid
•Do not use vague indefinable terms–Many words used informally to indicate quality are too vague
to be verified–Danger signs: user-friendly, highly versatile, flexible, to the
maximum extent, approximately, as much as possible, minimal impact
The Easy Entry System shall be easy to use and requirea minimum of training except for the professional mode.
X
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST 43
Writing errors to Avoid•Do not make multiple requirements
–Keep each requirement as a single sentence–Conjunctions (words that join sentences together) are
danger signs: and, or, with, also
•Do not use–Long sentences with arcane language –References to unreachable documents
The Easy Entry Navigator module shall consist of order entry and communications, order processing, result processing, and reporting. The Order Entry module shall beintegrated with the Organization Intranet System and results are stored in the group’s electronic customer record.
X
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST 44
Writing errors to Avoid•Do not speculate
– There is no room for “wish lists” – general terms about things that somebody probably wants
– Danger signs: vague subject type and generalization words such as usually, generally, often, normally, typically
•Do not express suggestions or possibilities– Suggestions that are not explicitly stated as requirements are
invariably ignored by developers– Danger signs: may, might, should, ought, could, perhaps,
probably•Avoid wishful thinking
– Wishful thinking means asking for the impossible (e.g., 100% reliable, safe, handle all failures, fully upgradeable, run on all platforms)
The Easy Entry System may be fully adaptable to all situations and often require no reconfiguration by the user.
X
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST 45
Requirements problem example
• “LIBSYS will be configurable so that it will comply with the requirements of international copyright legislation. Minimally, this means that LIBSYS must provide a form for the user to sign the Copyright Declaration statement. It also means that LIBSYS must keep track of Copyright Declaration statements which have been signed/not-signed. Under no circumstances must an order be sent to the supplier if the copyright statement has not been signed.”
Dig out the problems in this requirement
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST 46
Problems in example requirement • Incompleteness
– What international copyright legislation is relevant?– What happens if the copyright declaration is not signed?– If a signature is a digital signature, how is it assigned?– Recommendation:
• Define all copyright legislation as a separate requirement
• Reword requirement as “ copyright declaration must be signed before order is complete
• Introduce a new requirement for signature assignment
• Ambiguity– What does signing an electronic form mean? Is this a physical
signature or a digital signature?• Define what is meant by “signature”
• Standards– More than 1 requirement. Maintenance of copyright is one
requirement; issue of documents is another• Split the requirements in two or three separate requirements
Adv Software Engg, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST 47
Acknowledgement • SWEBOK Chapter 4• Requirements Engineering: A Roadmap
– Bashar Nuseibeh
• Software Requirements Engineering: What, Why, Who, When and How– Linda westfall
• Chapter 4 Software Engineering 9th edition – Ian Sommerville
• Requirements Engineering – Kotonya & Sommerville