Elicitation.As the first step in Requirements Engineering

"Elicitation Slides: Unveiling Insights Through Inquiry" is a comprehensive presentation that delves into the art of elicitation, the process of extracting valuable information through purposeful questioning and interaction. The presentation begins by defining elicitation and highlighting its significance in uncovering hidden knowledge, preferences, and perspectives. It outlines objectives such as understanding stakeholder needs, capturing tacit knowledge, and facilitating collaboration. The various techniques of elicitation, including brainstorming, interviews, and observation, are explored alongside best practices such as active listening and thorough documentation. Challenges such as stakeholder resistance and communication barriers are addressed, and real-world case studies demonstrate the effectiveness of elicitation in problem-solving and innovation. Additionally, the presentation covers tools and technologies to support elicitation efforts. Overall, it aims to equip the audience with the knowledge and tools necessary to leverage elicitation for informed decision-making and successful project outcomes.

1. BSE 3103: Requirements
Elicitation
Dr. Joseph Kibombo Balikuddembe
For comments and issues
[email protected].

5-Mar-21 1
© JK Balikuddembe - Requirements
Engineering

2. What Is Elicitation ?
•Process of identifying needs
•Front End to systems development
•Involves social, communicative issues and
Technical issues
•Requirement expression is the step to model
the requirements.

5-Mar-21 2
© JK Balikuddembe - Requirements
Engineering

3. Some basic points
•Elicitation is not Acquisition
•Requirements are not available like sensor
data Not just read them systematically !!
•Elicitation is not specification and modelling
•Too much importance has been given to
expression and modelling
•RE Determines the success of the mission
•Elicitation detrmines the success of the RE
process
5-Mar-21 3
© JK Balikuddembe - Requirements
Engineering

4. Requirements elicitation goals
•Identify and document business needs*; in order
to do so, you have to:
–Know the problem domain, in order to be able to
communicate with customers & users in their own
language.
–Know the current business model, in order to identify
needs, positive & negative aspects and potential
expectations.
–Know the technological environment, in order to
identify the technical restrictions of the system to be
developed.
5-Mar-21
© JK Balikuddembe - Requirements
Engineering
4

5. Elicitation Goals- Cont.
•“Never lose sight of why software is being
developed: to satisfy real needs, to solve real
problems. The only way to solve real needs is
to communicate with those who have the
needs. The customer or user is the most
important person involved with your project.”
5-Mar-21
© JK Balikuddembe - Requirements
Engineering
5

6. Elicitation goals Cont..
•Requirements elicitation goals – Information
systems should help their organizations to…
–Make competitiveness strategic decisions.
–Make business tactical decisions.
–Perform business processes and their related
operations.
•Most information systems developments are
operational-level oriented.
5-Mar-21
© JK Balikuddembe - Requirements
Engineering
6

7. Common generic problems


• Scope : too much or too little
•Establish a bounday conditions for the target system
• Organisation and context analysis
• Understandings : Users and developpers
• Users have an incomplete understanding of their
needs
• Analysts and SE have a poor knowledge of
problem domain
• Ease of omitting obvious information Volatility :
changing requirements
5-Mar-21 7
© JK Balikuddembe - Requirements
Engineering

8. Requirements Elicitation: Difficulties
and Challenges
•Communicate accurately about the domain and
the system
–People with different backgrounds must collaborate to
bridge the gap between end users and developers
•Client and end users have application domain knowledge
•Developers have solution domain knowledge
•Identify an appropriate system (Defining the
system boundary)
•Provide an unambiguous specification
•Leave out unintended features
5-Mar-21 8
© JK Balikuddembe - Requirements
Engineering

9. Requirements Specification vs Analysis
Model
Both focus on the requirements from the
user’s view of the system
•The requirements specification uses natural
language (derived from the problem
statement)
•The analysis model uses a formal or semi-
formal notation
–We use UML.



5-Mar-21 9
© JK Balikuddembe - Requirements
Engineering

10. Elicitation : a subset of goals
•Identify the relavant parties . The stackholders
•Gather the Wish List for each stachholder
•Document and refine the Wish list
•Expected properties
•Unambiguous
•Complete
•Verifiable
•Consistent
•Modifiable
•Traceable
•
5-Mar-21 10
© JK Balikuddembe - Requirements
Engineering

11. Elicitation:
Discover Stakeholder Requirements through
•Interviews
•Ethnographic studies (observe the user using similar
systems)
•Questionnaires
•Requirements workshops
•Brainstorming and idea reduction
•Storyboarding
•Study similar products & relevant docs
•Use cases
•Prototyping
•Context-free questions
5-Mar-21 11
© JK Balikuddembe - Requirements
Engineering

12. Analyst Role
•Observe and learn the user needs and tasks (the
problem) and understand them from the user point of
view
–What they are doing and why
•Interpret the user work/tasks
–Filter out technology and current way of doing things to get
to the essence of the work, not its incarnation
•Invent better ways to do the work
–Interpret what the product must do to satisfy the essential
requirements
•Record the results in the form of a requirements
specification and analysis models
•Validate that the analyst and user have the same
understanding of the problem and the product, and that
the user agrees that this is the product wanted
5-Mar-21 12
© JK Balikuddembe - Requirements
Engineering

13. Fact findings


User Developer
• Identify Stackholders
• Determine operational
and problem context
• Identify other systems
•´Perform context
analysis
• Identify domain
experts
• Id. Domain
• Conduct technological
survey
• Asses
cost/implementation

5-Mar-21 13
© JK Balikuddembe - Requirements
Engineering

14. Requirements gathering


User Developer
• Get Wish List

• Classify wish list
* Functional
* NFR
* Env.

5-Mar-21 14
© JK Balikuddembe - Requirements
Engineering

15. Evaluation and rationalisation
User Developer
• Perform abstraction
to answer question
• see interview
techniques
•Perform risk
assessment
• Cost benefit ...
5-Mar-21 15
© JK Balikuddembe - Requirements
Engineering

16. Prioritisation


User Developer
* Determine
criticality
• Prioritisation of
requirements
• basis : cost, criticality, ...
5-Mar-21 16
© JK Balikuddembe - Requirements
Engineering

17. Integration and validation


User Developer
•Adress completeness :
TBD type
• validate req with respect
concept of operation
• Decide to go on next
step
* Demo
* prototype
* ...
•Consistency checking

5-Mar-21 17
© JK Balikuddembe - Requirements
Engineering

18. The stackholder connection
•Sometimes called requirements analysis or
requirements discovery
•Involves technical staff working with customers
to find out about the application domain, the
services that the system should provide and
the system’s operational constraints
•May involve end-users, managers, engineers
involved in maintenance, domain experts,
trade unions, etc. These are called
stakeholders

5-Mar-21 18
© JK Balikuddembe - Requirements
Engineering

19. Gathering Information About...
•The organisation
–goals, structure, functional units, policies
•The people
–authority, duties, relationships, information, needs
•The work
–tasks, work flows, procedures, schedules, volumes,
performance criteria
•The work environment
–work areas, resources
5-Mar-21 19
© JK Balikuddembe - Requirements
Engineering

20. Gathering Information From...
•Documentation
–charts, manuals, job descriptions, forms, reports
•System users and managers
•External sources
–other companies, vendors, publications, seminars,
workshops, on-line data services

5-Mar-21 20
© JK Balikuddembe - Requirements
Engineering

21. Interviews
•The requirements engineer or analyst
discusses the system with different
stakeholders and builds up an understanding
of their requirements.
•Identify
•work flows
•factors that influence the operations of systems
•the elements (documents, procedures, policies
etc.) that make up systems

5-Mar-21 21
© JK Balikuddembe - Requirements
Engineering

22. Interview the User
•Interviewing is a common approach, but may not be
most effective

•Assumes users will know and be able to discuss their
requirements

•Questions often lead to specific answers and scope

•Questionnaire
–Consider it as pre-work to a personal interview

•Engage the user in the process so they are not passive
–Interactively build models, for example

5-Mar-21 22
© JK Balikuddembe - Requirements
Engineering

23. Interview Structure
•Set the interview in context to set scope and direction of
discussion
•Use business events as an anchor; work one event at a time
•Ask a question, listen to the answer, then feed back your
understanding
•Draw models and encourage user to change them
–Data flow models and work flow charts are effective
•Consider UML Activity Diagrams with data flow
•Use the user’s terminology and artifacts, both conceptual and
real
–Artifacts: papers, computers, meters, spreadsheets, machines,
instruction lists, software applications, etc.
–Avoid letting the user speak in technology/solution
•Keep sample artifacts and documents
•Thank the user for their time and tell them why it is valuable
5-Mar-21 23
© JK Balikuddembe - Requirements
Engineering

24. Types of Interviews
•Closed interviews
–The requirements engineer looks for answers to a
pre-defined set of questions
•goal-directed and systematic
•Open interviews
–There is no predefined agenda and the
requirements engineer discusses, in an open-
ended way, what stakeholders want from the
system.
•Appropriate when we want to explore an issue
•establish rapport and obtain a broad view
5-Mar-21 24
© JK Balikuddembe - Requirements
Engineering

25. Interviewing essentials
•Interviewers must be open-minded and should
not approach the interview with pre-conceived
notions about what is required
•Stakeholders must be given a starting point for
discussion. This can be a question, a
requirements proposal or an existing system
•Interviewers must be aware of organisational
politics - many real requirements may not be
discussed because of their political
implications

5-Mar-21 25
© JK Balikuddembe - Requirements
Engineering

26. Interview Steps
•Preparing
•Planning
•Opening and Closing
•Conducting
•Following up

5-Mar-21 26
© JK Balikuddembe - Requirements
Engineering

27. Preparing for the interview
•Review
•organisation reports
•annual reports
•statements of departments goals
•long-range planning goals
•existing procedure manuals
•systems documentation
•understand their language

5-Mar-21 27
© JK Balikuddembe - Requirements
Engineering

28. Planning of Interviews
•Identify sources
•prepare
* purpose, outline of points to cover
•venue
•appointments
•prepare the interviewee
* points to cover, useful documents

5-Mar-21 28
© JK Balikuddembe - Requirements
Engineering

29. Business Event Workshops
•Business events
–Businesses respond to events that are (typically) initiated
outside the scope of work to be done (by a user or an
adjacent system)
–A pre-planned response triggered by
•Arrival of information
•Arrival of request
•Passage of time
–The response to the event is a unit of work to be studied
•A use case
•In a business event workshop, the responsible user
describes or re-enacts the work that is done in
response to the event
–Identify data, processes, messages, subtasks,
checkpoints, etc.
–What contribution is to be made by the software
product?
5-Mar-21 29
© JK Balikuddembe - Requirements
Engineering

30. Business Event
Workshops
Requirements
Analyst
Event
Owner
Video for Recall
Generate Event-Response Scenarios
Use-case
scenario
Exceptions,
“what-if”
scenarios
Business Rules
Low-fidelity
Interaction
Screens
5-Mar-21 30
© JK Balikuddembe - Requirements
Engineering

31. Deliverables of the Business
Event Workshop
•Purpose of the business event
–Desired outcomes for the business
•Scenarios of the work (to be) done to respond to the
business event
•“What-if” scenarios about things that can go wrong
when the event happens
•The business rules that apply to that part of the work
•The part of the work to be done by the product
separated from the part that is done by people and
other systems
•The likely users of any product built for this event
•Prototypes for some of the steps
–Minimal detail
–Optional
5-Mar-21 31
© JK Balikuddembe - Requirements
Engineering

32. Purpose of the Business Event
•Focus on the outcome the organization hopes to
achieve whenever the event happens
–Think of outcomes, not outputs
–Example: car rental
•Outcomes: customer drives away in car of their choice, rate
selected is equitable, details are recorded, minimal customer and
clerk inconvenience, minimal cost
•Outputs: rental document, recorded data
•From organization’s view or customer’s view
–What are you trying to achieve?
–Why is this important?
•An outcome is a business objective, not a way of
achieving something
•Should be able to write in one sentence
–If this event happens, what state of affairs do you want to
exist when the work is finished responding?
5-Mar-21 32
© JK Balikuddembe - Requirements
Engineering

33. Requirements Analysis After
the Workshop
•Analyze each event response and answer:
–What does the product have to do to complete this
step?
–What non-functional requirements are necessary
for this step?
•Quality requirements
•Constraints
5-Mar-21 33
© JK Balikuddembe - Requirements
Engineering

34. Brainstorming
•Brainstorming is good for invention taking
advantage of the “group effect”
–“Invent” the need and/or the solution
–(See earlier slides on brainstorming)

•Use brainstorming to discover new requirements
and to create new possible solutions
–“Out there” ideas without criticizing or debating

•(In a requirements context) the best and most
usable ideas will, with the client’s consent, become
requirements for the product
5-Mar-21 34
© JK Balikuddembe - Requirements
Engineering

35. Rules for Brainstorming
•Diverse disciplines and backgrounds
•For this session, suspend judgment, evaluation, and criticism
–Don’t stop the creative flow
•Produce lots of ideas
–Quantity will, in time, produce quality
•Come up with ideas that are unconventional, crazy, wild, etc.
–This will produce really useful requirements
•Piggyback a new idea on an old one – use ideas to stimulate new ideas
•Write every idea down, without censoring
–“Ideas disappear faster than water evaporates unless written down” [Alex Osborne, the
founder of brainstorming]
•If you get stuck, seed the session with a word pulled randomly from a dictionary
–Word associations, using the word as a springboard
5-Mar-21 35
© JK Balikuddembe - Requirements
Engineering

36. After the Brainstorming
Session
•Analysts and clients evaluate the ideas
–Some worthless, but they will have served their
purpose of inspiring other, more practical, ideas
–Keep the best and (if feasible) turn them into
requirements
•Merge ideas
–Merge half-formed ideas into an invention
•Form half-formed ideas into true requirements
•Investigate ideas with additional trawling
techniques

5-Mar-21 36
© JK Balikuddembe - Requirements
Engineering

37. Context-Free Questions
– Process-Oriented
•User
–Who is the customer?
–Who is the user?
–Are their needs different?
–What are their backgrounds, capabilities, environments?
•What is the reason for wanting to solve this problem?
•What is the value of a successful solution?
•How do you solve the problem now?
–Can we copy that solution?
•How much time do we have?
–What is the trade-off between time and value?
–Who should be on the team(s)?
5-Mar-21 37
© JK Balikuddembe - Requirements
Engineering

38. Context-Free Questions
– Product-Oriented
•What problems does this system solve?

•What problems could this system create?

•What environment will the product be used in?

•What are your expectations for usability, reliability,
performance, etc.?
5-Mar-21 38
© JK Balikuddembe - Requirements
Engineering

39. Context-Free Questions
– Meta-questions
•Am I asking too many questions?
•Do my questions seem relevant?
•Are you the right person to answer these questions?
•To assure we understand each other, may I write down the answers to
these questions and give you a written copy to study and approve?
•Is there someone else who can give me useful answers?
•Is there some way I can see the environment in which the product will
be used?
•Are your answers official requirements?
•Is there anything else I should be asking you?
•Is there anything you want to ask me?
•Can I ask more questions later?
5-Mar-21 39
© JK Balikuddembe - Requirements
Engineering

40. Group Dynamics:
Be sensitive to them & probe
them
•I noticed you hesitated (had trouble describing, etc.). Is there something
else we should know?
•When I asked X about that, she said Y. Do you have any idea why she might
have said Y?
•I notice you don’t seem to agree with that reply. Would you tell us about
that?
•Are you comfortable with the process right now?
•Is there any reason you don’t feel you can answer freely?
•What can you tell me about the other people on this project?
•How do you feel about the other people working with us on this project?
•Is there anybody we need on this project whom we don’t have?
•Is there anybody we have on this project whom we don’t need?
5-Mar-21 40
© JK Balikuddembe - Requirements
Engineering

41. Plan Your Tasks
•Identify the techniques that are most appropriate
and will have the greatest impact

•What resources to do have?

•Is there any sort of research that you need to do?

•Distribute the work and manage your time
5-Mar-21 41
© JK Balikuddembe - Requirements
Engineering

42. Your Project
•Identify the elicitation techniques that are appropriate
and have the greatest impact.

•What tasks are involved to plan, execute and
document the results for each identified technique?

•What stakeholders will you interact with for each
technique?

•How much time do you plan for each technique?
5-Mar-21 42
© JK Balikuddembe - Requirements
Engineering

43. Questioning
•Open questions
–tell me what happens when a customer calls
•leading questions
•be wary of negative responses
–exceptions?
•Subjects who try to please

5-Mar-21 43
© JK Balikuddembe - Requirements
Engineering

44. Listening
•Judge content and not delivery
•withhold evaluation and response
•be flexible
•work at listening
•resist distractions
•keep your mind open
•listen for ideas

5-Mar-21 44
© JK Balikuddembe - Requirements
Engineering

45. Opening and closing and Following Up the interview
•Introduce yourself
•state the purpose of the interview
•briefly summarise the areas that have been
discussed, highlight important points and your
understanding of them
•thank the interviewee for the time
•Ask closed questions
•Document the results

5-Mar-21 45
© JK Balikuddembe - Requirements
Engineering

46. Questionnaires
•Validity
- sample size, audience
•Reliability
•Questions
- open ended
- fill in the blank
- multiple choice
- rating scales

5-Mar-21 46
© JK Balikuddembe - Requirements
Engineering

47. Scenarios
•Scenarios are stories which explain how a
system might be used. They should include
- a description of the system state before
entering the scenario
- the normal flow of events in the scenario
- exceptions to the normal flow of events
- information about concurrent activities
- a description of the system state at the end
of the scenario
5-Mar-21 47
© JK Balikuddembe - Requirements
Engineering

48. Scenarios
•Scenarios are examples of interaction sessions
which describe how a user interacts with a
system
•Discovering scenarios exposes possible system
interactions and reveals system facilities which
may be required
 Operational semantics
5-Mar-21 48
© JK Balikuddembe - Requirements
Engineering

49. Observation and social analysis
•People often find it hard to describe what they
do because it is so natural to them.
–Sometimes, the best way to understand it is to
observe them at work
•Ethnography is a technique from the social
sciences which has proved to be valuable in
understanding actual work processes
•Actual work processes often differ from
formal, prescribed processes

5-Mar-21 49
© JK Balikuddembe - Requirements
Engineering

50. Meetings
•Meetings consume resources
•must improve quality of meetings
•Meetings have different objectives
•solve problems, clarify issues
•brainstorm solutions to problems
•resolve conflicts
•conduct reviews
•collect and merge facts and data
•report progress
•assign actions
5-Mar-21 50
© JK Balikuddembe - Requirements
Engineering

51. Meetings: Planning
•Define clearly the expected results or
outcomes of the meeting
•Find if possible a way to eliminate the need for
the meeting
•do we really need the outcome of this meeting at
this moment?
•Is there another more efficient and more effective
way to accomplish what is to be accomplished by
holding this meeting?
•If yes and no are the answers to the two questions
then proceed
5-Mar-21 51
© JK Balikuddembe - Requirements
Engineering

52. Meetings: Planning
•Prepare agenda for the meeting
•reasonable time allocation for each topic
• circulate at least two days before the meeting
•to allow time for the attendees to prepare, comment and make
schedule arrangements
•identify and notify required meeting attendees. Must have the
right people
•the appropriate information and knowledge to support meeting
goals and objectives
•the authority )direct or delegated) to make decisions and
commitments if required by the meeting’s goals and objectives
•the need to understand what is going on and the rationale
behind any decisions or commitments made during the meeting
5-Mar-21 52
© JK Balikuddembe - Requirements
Engineering

53. Meetings: Planning
•Meeting location considerations
•room size, lighting, noise, temperature, humidity can
distract
• need for audio/visual aids in working order
•Start and Finish on time
•Record and publish minutes
•Have handouts ready for distribution
•review the agenda, meeting goals and objectives first
•discourage interruptions and deflections from the
topic at hand
•follow the agenda schedule as closely as possible
5-Mar-21 53
© JK Balikuddembe - Requirements
Engineering

54. Active Listener Guidelines
•Clear your mind of everything except the speaker, the
topic and what the speaker is actually saying. Prevent
trying to read more into what the speaker is saying
than the speaker is actually saying
•Capture as accurately as possible the information that
the speaker is conveying
•Let the speaker know by actions that s/he is
interested in what is being said
•Ask questions as they arise to clarify points, indicate
understanding and provide feedback to the speaker

5-Mar-21 54
© JK Balikuddembe - Requirements
Engineering

55. Active Listener Guidelines
•Ask that the central ideas, themes and summaries be
repeated to assure complete understanding
•Do not attempt to formulate replies, rebuttals or
counterexamples while the speaker is talking
•Do not draw conclusions until you have heard the
whole story
•Accept that understanding is not agreeing
•Do not be afraid to ask if there is something that you
have not been told.
5-Mar-21 55
© JK Balikuddembe - Requirements
Engineering

56. Typical Comparison Questions
•For the comparison one may ask
•Does the methodology cover all phases? Which ones? How
thoroughly.
•Are the steps fairly proceduralised or does the
methodology only give broad directions? Are analysis,
design and implementation given equal weight?
•Is it data or process analysis oriented?
•Does it cover prototyping and incremental development?
•How are the results of analysis and design expressed?
•Is the methodology supported by software?
•What types of applications is it suited to? History?
5-Mar-21 56
© JK Balikuddembe - Requirements
Engineering

57. Decomposition Diagrams
•A high-level organisation (or function or activity) is
decomposed into lower organisations (or functions or
activities). The lower we go in the hierarchy the
greater the detail revealed
•Used to show organisation, system, program, file and
report structures
•organisation
•functions
•processes
•procedures
•program structures
5-Mar-21 57
© JK Balikuddembe - Requirements
Engineering

58. Types of Requirements
•Functional requirements
–Describe the interactions between the system and its
environment independent from the implementation
“An operator must be able to define a new game. “
•Nonfunctional requirements
–Aspects not directly related to functional behavior.
“The response time must be less than 1 second”
•Constraints
–Imposed by the client or the environment
•“The implementation language must be Java “
–Called “Pseudo requirements” in the text book.
5-Mar-21 58
© JK Balikuddembe - Requirements
Engineering

59. Functional vs. Nonfunctional
Requirements
Functional Requirements
•Describe user tasks that the
system needs to support
•Phrased as actions
“Advertise a new league”
“Schedule tournament”
“Notify an interest group”


Nonfunctional Requirements
•Describe properties of the
system or the domain
•Phrased as constraints or
negative assertions
“All user inputs should be
acknowledged within 1 second”
“A system crash should not result in
data loss”.
5-Mar-21 59
© JK Balikuddembe - Requirements
Engineering

60. Types of Nonfunctional Requirements
•Usability
•Reliability
–Robustness
–Safety
•Performance
–Response time
–Scalability
–Throughput
–Availability
•Supportability
–Adaptability
–Maintainability
•Implementation
•Interface
•Operation
•Packaging
•Legal
–Licensing (GPL, LGPL)
–Certification
–Regulation
Quality requirements
Constraints or
Pseudo requirements
5-Mar-21 60
© JK Balikuddembe - Requirements
Engineering

61. Some Quality Requirements
Definitions
•Usability
–The ease with which actors can use a system to
perform a function
–Usability is one of the most frequently misused
terms ((“The system is easy to use”)
–Usability must be measurable, otherwise it is
marketing
•Example: Specification of the number of steps – the
measure! - to perform a internet-based purchase with
a web browser
5-Mar-21 61
© JK Balikuddembe - Requirements
Engineering

62. Some Quality Requirements
Definitions
•Robustness: The ability of a system to maintain
a function
–even if the user enters a wrong input
–even if there are changes in the environment
•Example: The system can tolerate temperatures up to 90 C
•Availability: The ratio of the expected uptime of a
system to the aggregate of the expected up and
down time
–Example: The system is down not more than 5
minutes per week.
5-Mar-21 62
© JK Balikuddembe - Requirements
Engineering

63. Nonfunctional Requirements:
Examples
•“Spectators must be able to watch a match
without prior registration and without prior
knowledge of the match.”
Usability Requirement
•“The system must support 10 parallel
tournaments”
Performance Requirement
•“The operator must be able to add new games
without modifications to the existing system.”
Supportability Requirement
5-Mar-21 63
© JK Balikuddembe - Requirements
Engineering

64. What should not be in the
Requirements?
•System structure, implementation technology
•Development methodology
–Parnas, How to fake the software development
process
•Development environment
•Implementation language
•Reusability
•It is desirable that none of these above are
constrained by the client.
5-Mar-21 64
© JK Balikuddembe - Requirements
Engineering

65. Different Types of Requirements
Elicitation
•Greenfield Engineering
–Development starts from scratch, no prior system
exists, requirements come from end users and clients
–Triggered by user needs
•Re-engineering
–Re-design and/or re-implementation of an existing
system using newer technology
–Triggered by technology enabler
•Interface Engineering
–Provision of existing services in a new environment
–Triggered by technology enabler or new market needs
5-Mar-21 65
© JK Balikuddembe - Requirements
Engineering

66. Prioritizing requirements
•High priority
–Addressed during analysis, design, and
implementation
–A high-priority feature must be demonstrated
•Medium priority
–Addressed during analysis and design
–Usually demonstrated in the second iteration
•Low priority
–Addressed only during analysis
–Illustrates how the system is going to be used in the
future with not yet available technology
5-Mar-21 66
© JK Balikuddembe - Requirements
Engineering

67. Nonfunctional Requirements
•User interface and human factors
•Documentation
•Hardware considerations
•Performance characteristics
•Error handling and extreme conditions
•System interfacing
•Quality issues
•System modifications
•Physical environment
•Security issues
•Resources and management issues
5-Mar-21 67
© JK Balikuddembe - Requirements
Engineering

68. Nonfunctional Requirements
User interface and human factors
–What type of user will be using the system?
–Will more than one type of user be using the system?
–What training will be required for each type of user?
–Is it important that the system is easy to learn?
–Should users be protected from making errors?
–What input/output devices are available
Documentation
–What kind of documentation is required?
–What audience is to be addressed by each
document?
5-Mar-21 68
© JK Balikuddembe - Requirements
Engineering

69. Nonfunctional Requirements (2)
Hardware considerations
–What hardware is the proposed system to be used on?
–What are the characteristics of the target hardware,
including memory size and auxiliary storage space?
Performance characteristics
–Are there speed, throughput, response time constraints
on the system?
–Are there size or capacity constraints on the data to be
processed by the system?
Error handling and extreme conditions
–How should the system respond to input errors?
–How should the system respond to extreme conditions?
5-Mar-21 69
© JK Balikuddembe - Requirements
Engineering

70. Nonfunctional Requirements (3)
System interfacing
–Is input coming from systems outside the proposed
system?
–Is output going to systems outside the proposed system?
–Are there restrictions on the format or medium that must
be used for input or output?
Quality issues
–What are the requirements for reliability?
–Must the system trap faults?
–What is the time for restarting the system after a failure?
–Is there an acceptable downtime per 24-hour period?
–Is it important that the system be portable?
5-Mar-21 70
© JK Balikuddembe - Requirements
Engineering

71. Nonfunctional Requirements (4)
System Modifications
–What parts of the system are likely to be modified?
–What sorts of modifications are expected?
Physical Environment
–Where will the target equipment operate?
–Is the target equipment in one or several locations?
–Will the environmental conditions be ordinary?
Security Issues
–Must access to data or the system be controlled?
–Is physical security an issue?
5-Mar-21 71
© JK Balikuddembe - Requirements
Engineering

72. Nonfunctional Requirements (5)
Resources and Management Issues
–How often will the system be backed up?
–Who will be responsible for the back up?
–Who is responsible for system installation?
–Who will be responsible for system maintenance?

5-Mar-21 72
© JK Balikuddembe - Requirements
Engineering

73. 73
Example Functional Requirements
•List all functional requirements
–with proper numbering.
•Req. 1:
–Once the user selects the “search” option,
•he is asked to enter the key words.
–The system should output details of all books
•whose title or author name matches any of the key
words entered.
•Details include: Title, Author Name, Publisher name,
Year of Publication, ISBN Number, Catalog Number,
Location in the Library.
5-Mar-21
© JK Balikuddembe - Requirements
Engineering

74. 74
Example Functional Requirements
•Req. 2:
–When the “renew” option is selected,
•the user is asked to enter his membership number
and password.
–After password validation,
•the list of the books borrowed by him are displayed.
–The user can renew any of the books:
•by clicking in the corresponding renew box.
5-Mar-21
© JK Balikuddembe - Requirements
Engineering

75. 75
Req. 1:
•R.1.1:
–Input: “search” option,
–Output: user prompted to enter the key words.
•R1.2:
–Input: key words
–Output: Details of all books whose title or author name
matches any of the key words.
•Details include: Title, Author Name, Publisher name, Year of
Publication, ISBN Number, Catalog Number, Location in the
Library.
–Processing: Search the book list for the keywords
5-Mar-21
© JK Balikuddembe - Requirements
Engineering

76. 76
Req. 2:
•R2.1:
–Input: “renew” option selected,
–Output: user prompted to enter his
membership number and password.
•R2.2:
–Input: membership number and password
–Output:
•list of the books borrowed by user are displayed.
User prompted to enter books to be renewed or
•user informed about bad password
–Processing: Password validation, search books
issued to the user from borrower list and
display.
5-Mar-21
© JK Balikuddembe - Requirements
Engineering

77. 77
Req. 2:
•R2.3:
–Input: user choice for renewal of the books issued
to him through mouse clicks in the corresponding
renew box.
–Output: Confirmation of the books renewed
–Processing: Renew the books selected by the in the
borrower list.
5-Mar-21
© JK Balikuddembe - Requirements
Engineering