Requirement Engineering (2)

Requirements Determination

Dr. Foziah Gazzawe & Dr. Mohamed Nour

Topics
n From business processes to solution envisioning

n Functional and nonfunctional requirements

n Requirements elicitation
• traditional methods and modern methods

n Requirements negotiation and validation

n Requirements management

n Requirements business model

• system scope, business use case model, business glossary,
business class model

n Requirements document

2
1. Frombusiness processes to solution
envisioning

n IT solutions address business problems

n IT solutions are enablers of business
innovation
n IT solution is an infrastructure service (a
commodity)
What is an IT solution?
n A business solution
n Implementation of a business process
n Sometimes an enabler of business innovation
n An infrastructure service
n A commodity (http://en.wikipedia.org/wiki/Commodity)
• “derived from the French word "commodité" , meaning
today's "convenience" in term of quality of services
• “an undifferentiated product whose value arises from the
owner's right to sell rather than buy” – like electricity or
music

4
BPMN- Business Process Modeling Notation
n Developed by a consortium Business Process Management
Initiative
n Managed by the OMG within the task force Business Modeling
& Integration Domain Task Force (BMI DTF)
n Dedicated to modeling business processes defined as
activities that produce something of value to the organization
or to its external stakeholders
n UML activity diagrams – a competing notation
n A goal is to map these notations to an executable language
• in particular to the Business Process Execution Language
(BPEL) – a standard for process execution in systems based on
the Service Oriented Architecture (SOA)

5
Process hierarchy modeling
n A process may contain other processes (sub-
processes)

n An atomic activity within a process is called a task

n A process hierarchy diagram – not part of BPMN
• A business process can be performed manually or an
automated service

• A process has at least one input flow and one output flow
– When the process gains the control, it performs its activity,
typically by transforming the input flow into the output flow

• A process can be atomic or composite

6
 Process hierarchy diagram - notation

Composite process

Atomic process(task) Composite processwith subprocessessuppressed

7
 Process hierarchy model (advertising expenditure)
Advertising Expenditure Measurements

Measurement Collection

Measurement Verification

Measurement Valorization

Enter Non-Electronic Data Reporting and Distribution

Download Electronic Data Translate and Format Data

Contact Management

Contracts and Accounts Receivable

8
BPMNflow objects
n BPMN offers four basic categories of
modeling elements:
• Flow objects:
– Events
– Activities
– Gateways

• Connecting objects
• Pools (Swimlanes)
• Artifacts

9
BPMN– events and activities
• An event is something that “happens”.
• There are various types of events, such as timer, error, or cancel.

• An activity represents some work that must be done.

• This could be a task or a sub-process.

10
BPMN- gateways
A gateway is used to control the divergence and convergence of multiple sequence flows.

11
 BPMN– connecting objects
The connecting objects (or connectors) are used to connect flow objects
in order to define the structure of a business process.

• A sequence flow is used to show the order in which the activities will be performed in a process.
• A message flow is used to show the flow of messages (data) between two business entities (two process participants)
that are prepared to send and receive them.
• An association is used to associate flow objects or to associate artifact with a flow object.

12
BPMN– pools (swimlanes)
• A pool represents a business entity (participant) in a process.
•It acts as a “swimlane” mechanism to organize activities into separate visual categories
in order to illustrate different functional capabilities or responsibilities.
• Pools represent sets of self-contained processes.
• Accordingly, the sequence flow may not cross the boundary of a pool.
• Participants in various pools can communicate via message flows or associations to artifacts.

vertical pool

13
 BPMN- artifacts
Artifacts provide additional modeling flexibility by allowing to extend the basic notation
to respond to specific modeling situations, such as for so-called vertical markets
(e.g. telecommunication, hospitals or banking).

group
data object
annotation

• Data objects represent data required or produced by activities.

• A group is a grouping of activities that does not affect the sequence flow of the process.
The grouping can be used for documentation or analysis purposes
(e.g. to identify the activities of a distributed transaction across pools).
• Annotations provide additional text information for the reader of a business process diagram.

14
Business process model (advertising expenditure)

15
Solution envisioning
n Solution envisioning is a business value-
driven approach to delivering an IT service
(i.e. not merely a software system)
• to solve an As-Is business problem or
• to foster a To-Be business innovation.
n Solution envisioning makes a close
connection between business and IT
stakeholders and integrates business
strategy methods and software development
capabilities.
n It is about the three “E-s” – efficiency,
effectiveness, and edge.

16
Three phases of solution envisioning process
n Business capability exploration – determines business
capabilities understood as the capacities relating to how a
business IT solution can deliver specific results.
• This phase describes capability cases – solution ideas making
the business case for each capability.
n Solution capability envisioning – aims at developing the
capability case into a solution concept and at ensuring that the
solution is agreed upon by the stakeholders.
• The solution concept takes the business context as input and
produces future scenarios for new ways to work as output.
• The solution concept converges on the ultimate solution
architecture and is developed in solution envisioning workshops.
n Software capability design – decides on system
implementation technologies, develops software capability
architecture, and elaborates the business case with project
plans and risk analysis.
• Software capability design is an activity in software modeling.

17
Three phases of solution envisioning process

18
Implementation strategy and capability architecture
n In the first phase of the solution envisioning process,
capability cases function as multiple solution sketches to allow
many solution possibilities to be explored.
n Later on, the selected capability cases become technical
blueprints for the solution.
n Finally, three prevalent implementation strategies need to be
considered:
• Custom development
– performed in-house and/or
– contracted out to consulting and development firms.
• Package-based development that derives the solution by
customizing pre-existing software packages, such as COTS,
ERP or Customer Relationship Management (CRM) systems.
• Component-based development that builds the solution by
integrating software components sourced from multiple vendors
and business partners and likely to be based on SOA and/or
MDA.

19
2. Requirements elicitation

n The least technical phase of system development

n Demands social, communication and managerial
skills
n Delivers a (mostly narrative) definition of user
requirements
Requirements
n Requirements define
• System services ® functional requirements
– scope of the system
software system =
– necessary business functions algorithms + data structures

– required data structures

• System constraints ® nonfunctional

requirements
– regarding ‘look and feel’, performance, security, etc.
– also known as supplementary requirements

22
Functional and nonfunctional requirements
n Requirements elicitation
• concerned mostly with functional reqs
• ...but nonfunctional requirements cannot be
an afterthought
n Reviews and re-negotiations
n Requirements document
n A moving target even after the req doc is
signed off
• requirements management is concerned, inter
alia, with managing change and estimating the
impact of change on the project

23
Nonfunctional requirements
n Usability – ease of use
• documentation and help, training, user interface, error handling
n Reusability – ease of component reuse
n Reliability
• mean time between failures, graceful recovery, uninterrupted
availability, accuracy of results
• reliable = dependable (we can depend on it)
n Performance
• response time, transaction throughput, resource consumption,
concurrency level
n Efficiency – in terms of time and cost
n Supportability = understandability + maintainability +
scalability
n Other constraints
• policy decisions, legal issues, portability and interoperability
demands, timeliness of product delivery

24
 Requirements elicitation

capture the unique

character of the
Domain Expert organization Customer

general time-
independent business
rules and processes
Domain Knowledge Use Case
Business Analyst
Requirements Requirements

Business Model

Business Class Model Business Use Case Model

Class – an abstraction that describes a set of objects

with common attributes, operations, relationships, and constraints Use case – a major functional unit

25
Traditional methods of requirements elicitation

n Simple and cost effective

n When clear objectives and low project risks

n Include:

• Interviewing customers and domain experts

• Questionnaires

• Observation

• Study of documents and software systems

26
Interviewing customers and domain experts
n With customers – mostly use case reqs
n With domain experts – frequently a straight knowledge transfer
n Structured (formal) interview
• Open-ended questions (unanticipated responses)

• Close-ended questions (a list of possible responses known)

n Unstructured (informal) interview

n Questions to be avoided
• Opinionated questions (do we have to do things the way we do them?)
• Biased questions (you are not going to do this, are you?)
• Imposing questions (you do things this way, don’t you?)
n Summary report of the interview should be sent to the interviewee
within a day or two, along with a request for comments

27
Interview – kinds of questions
n about specific details
• five Ws: what, who, when, where, and why.
n about vision for the future
n about alternative ideas
• these may be questions to an interviewee and suggestions
from the interviewer asking for opinions
n about minimally acceptable solution to the problem
• good usable systems are simple systems
n about other sources of information
• can discover important documents and other knowledge
sources unknown before to the interviewer
n soliciting diagrams
• drawn by an interviewee to explain business processes
may prove invaluable for understanding the requirements

28
Questionnaires
n In addition to interviews
n A passive technique
• advantage – time to consider the answers
• disadvantage – no possibility to clarify questions and answers
• who are the people which did not respond? how would they
respond?
n Close-ended questions
• Multiple-choice questions
– additional comments may be allowed
• Rating questions (e.g. strongly agree, agree, ...)
– when seeking opinions
• Ranking questions
– ranked with numbers, percent values, etc.

29
Observation
n In addition to interviews (and possibly questionnaires)
n When the user cannot convey sufficient information and/or
has only fragmented knowledge
n Three forms
• Passive
– no interruption or direct inmvolvement
– video camera may be used
• Active
• Explanatory
– explaining what is done when observed
n Should be carried for a prolonged time, at different times and
at different workloads
n People tend to behave differently when watched
• ‘work to rule’ is a form of industrial action
• ‘knowledge work’ is not susceptible to observation

30
Study of documents and software systems
n Always used, but may target portions of the system

n Use case requirements

• Organizational documents
– including procedures, policies, descriptions, plans, charts, internal
and external correspondence

• System forms and reports (if prior computer system exists)

– record of change requests (defects and enhancements)

n Domain knowledge requirements

• domain journals and reference books

• ERPSs

• using Internet searches

31
Modern methods of requirements elicitation
n Offer better insights at higher cost and effort

n When high project risks (unclear objectives, undocumented

procedures, unstable requirements, eroded user expertise,

inexperienced developers, insufficient user commitment, etc.)

n Include:

• Prototyping

• Brainstorming

• Joint Application Development (JAD)

• Rapid Application Development (RAD)

32
Prototyping
n ‘Quick and dirty’ solution to obtain feedback

n Necessary in complex and innovative projects

n Two kinds:

• Throw-away prototype

– targets requirement determination

• Evolutionary prototype

– targets the speed of product delivery

33
Brainstorming
n to form new ideas or to find a solution to specific problem by
putting aside judgment, criticism, social inhibitions and rules
n to reach consensus among stakeholders
n ‘cool’ analysis and decision making done afterwards
n The process:
• prior to meeting, the facilitator provides probortunity statement
(the problem/opportunity area)
– generic trigger questions to challenge the participants (e.g. what
features should the system support? what are the main ‘business
objects’?
• 12 to 20 participants around a table, feeling equal with the
facilitator “one of the crowd”
• answers to trigger questions recorded and passed around to
stimulate more answers/ideas
• answers/ideas get anonymous
• answers/ideas are discussed
• voting to prioritize answers/ideas

34
3. Requirements negotiation
and validation

nelicited requirements need to

undergo careful negotiation and
validation with all stakeholders
Requirements negotiation and validation
n Needed because reqs
• overlap and conflict ® requirements dependency matrix
(next slide)
• may be ambiguous or unrealistic
• may remain undiscovered
• may be out of scope (as captured by a reference model
such as a context diagram (explained later))
– sometimes out of the “project” scope, but in the scope of the
“information system” (req too difficult to implement and
should be done manually, may be of low priority, may be
implemented in hardware)
n frequently done in parallel with requirements
elicitation
n inseparable from the production of requirements
document
• negotiation starts from the draft req doc
• validation reviews and ‘rubber stamps’ the doc

39
Requirements dependency matrix

Requirement R1 R2 R3 R4

R1

R2 Conflict

R3

R4 Overlap Overlap

40
Requirements risks and priorities
n Risk is a threat to the project plan
n Risks determine project’s feasibility
n Risk analysis identifies requirements that are likely to cause
development difficulties
n Prioritization is needed to allow easy rescoping of the project
when faced with delays
n Risk categories
• Technical
• Performance
• Security
• Database integrity
• Development process
• Political
• Legal
• Volatility

41
4. Requirements management

n requirements identification and classification

n requirements hierarchies
n change management
n requirements traceability
Requirements identification and classification
n Natural language statements
• ‘The system shall schedule the next phone call to a customer
upon telemarketer’s request.’

n Identification and classification scheme

• Unique identifier (automatically generated)
– database generated, if possible
– including version number, if possible
• Sequential number with document hierarchy
– the seventh requirement in the third section of the second chapter
would be numbered 2.3.7

• Sequential number with requirement’s category

– where the categories of requirements can be: function requirement,
data requirement, performance requirement, security requirement,
etc

44
Requirements hierarchies
n Parent-child relationships
n Reflect varying abstraction levels
1. "The system shall schedule the next
phone call to a customer upon
telemarketer's request."
1. “The system shall activate Next Call push
button upon entry to Telemarketing Control
form or when the previous call has terminated.”
2. “The system shall remove the call from the top
of the queue of scheduled calls and make it the
current call.”
3. etc.

45
Change management
n A requirement may change, be removed, or
a new requirement may be added
n Downstream cost of change
n Strong management policies needed to
• document change requests,
• to assess a change impact,
• and to effect the changes
n Requirements changes should be stored
and tracked by a software configuration
management tool

46
Requirements traceability
n A critically important part, of change

management

n A suspect trace – after change to any

element in a traceability relationship

n More in Chapter 9

47
5. Requirements business model

n a high-level visual representation of

elicited, negotiated and validated
requirements
 Requirements business model
Test
Model
User manuals

Project planning

Business
Use Case
Use Case
Model
Model
System
Scope Implementation
Model Model
Business
Class
Class
Model
Model
Design
Requirements Requirements
Determination Specification
Model

50
Context diagram - notation

51
 Business use case diagram- notation
communication
relationship

Business use case º

system feature;
IS process and/or manual
activity

Business actor =
primary and/or secondary
(external/internal dichotomy)

55
Business use case diagram- telemarketing

56
Business glossary
Term definition

bonus A specialseriousofactivities, conductedwithin acampaign, to additionally

campai entice supporters to buy the campaign tickets. Typical examples are giving
gn freetickets forbulk orearlybuyingorforattracting newsupporters. A
particular kind of bonus campaign can beused in many campaigns.

campaign A governmentapprovedand carefullyplanned seriesofactivities whichare

intended to achieve a lottery objective.

draw An act of randomly choosing a particular lottery ticket as a winning ticket.

lottery A funds raisinggameofchance,organizedbythe charityin order to make

money, in which people (supporters) buy numbered tickets to
have a chance of winning a prize if their number is chosen in a
draw.
placement Acquisition of oneor morelottery tickets by a supporter during
telemarketing. The placement is paid by a supporter with a credit
card.
57
6. Requirements document

n a tangible outcome of the

requirements determination phase
n produced according to an
organization-approved template
Requirements document
R e q u ir e m e n t s D o c u m e n t
T a b le o f C o n te n ts

1. P r o je c t P r e lim in a r ie s
1 .1 P u rp o se a n d S c o p e o f th e P ro d u c t
1 .2 B u sin e ss C o n te x t
1 .3 S ta k e h o ld e rs
1 .4 Id e a s fo r S o lu tio n s
1 .5 D o c u m e n t O v e rv ie w
2 . S y ste m S e r v ic e s
2 .1 T h e S c o p e o f th e S yste m
2 .2 F u n c tio n R e q u ire m e n ts
2 .3 D a ta R e q u ire m e n ts
3 . S y ste m C o n str a in ts
3 .1 In te rfa c e R e q u ire m e n ts
3 .2 P e rfo rm a n c e R e q u ire m e n ts
3 .3 S e c u rity R e q u ire m e n ts
3 .4 O p e ra tio n a l R e q u ire m e n ts
3 .5 P o litic a l a n d Le g a l R e q u ire m e n ts
3 .6 O th e r C o n stra in ts
4 . P ro je c t M a tte rs
4 .1 O p e n Is s u e s
4 .2 P re lim in a ry S c h e d u le
4 .3 P re lim in a ry B u d g e t
A p p e n d ic e s
G lo ssa ry
B u sin e ss D o c u m e n ts a n d F o rm s
R e fe re n c e s

62
Project preliminaries
n Targets managers and decision makers
n Begins with purpose and scope of the
project
n Makes a business case for the system
n Identifies stakeholders
n Offers initial ideas for the solution
• including off-the-shelf solutions
• off-the-shelf does not dispense with the need for
RASD
n Includes an overview of the rest of the
document
63
Systemservices
n Dedicated to the definition of system
services - what the system must
accomplish
n Likely to account for more than half of the
entire document
n Contains high-level requirements business
models
• Context diagram (the system scope)
• Business use case diagram (function
requirements)
• Business class diagram (data requirements)
– main attributes, but no operations
• Business glossary moved to the Appendix

64
System constraints
n Dedicated to the definition of system
constraints - how the system is constrained
when accomplishing services with regard to
• Interface requirements
– ‘look and feel’ only
• Performance requirements
– response times, but also reliability, availability,
throughput indicators
• Security requirements
– access privileges
• Operational requirements
– hardware/software environment
• Political and legal requirements
• Other constraints
– usability
– maintainability

65
Project matters
n Open issues
• Future requirements
• Current requirements to be implemented in the
future – enhancements
• Potential problems when the system is deployed
n Preliminary schedule
• Human and other resources
• Planning charts (PERT, Gantt)
n Preliminary budget
• Project cost – range rather than figure
• In some cases, better estimation possible (e.g.
function point analysis)

66
Summary
n The analysis of business processes drives development of
information systems
n The choice of implementation strategy determines the capability
architecture of the system
n Requirements determination is about discovering requirements
and documenting them
n Two lines of discovery – the discovery from the domain knowledge
and from the use cases
n Methods of requirements elicitation include interviewing
customers and domain experts, questionnaires, observation, study of
documents and software systems, prototyping, JAD and RAD
n Requirements negotiation and validation to resolve overlaps and
conflicts
n Requirements have to be managed
n Requirements business model uses diagrams – Context Diagram,
Business Use Case Diagram, and Business Class Diagram
n The resulting document is called the Requirements Document

69