Determining System
Requirements
Introduction
An organizational approach to systems analysis
2
Systems Development Life Cycle (SDLC)
• Traditional methodology used to plan, analyze, develop,
maintain, and replace information systems.
• Phases in SDLC:
• Planning
• Analysis
• Design
• Implementation
• Maintenance
3
Traditional Waterfall SDLC
One phase begins
when another
completes, with
little backtracking
and looping.
A traditional waterfall SDLC: rarely used
4
The Heart of the Systems Development Process
The analysis–design–code–test loop The heart of systems development
Current practice combines analysis, design, and implementation
into a single iterative and parallel process of activities.
Predictive Approaches
• Joint Application Development (JAD)
• Rapid Application Development (RAD): incremental
• Object Oriented Approach
6
Adaptive Approaches: Agile
• Motivated by recognition of software development as fluid,
unpredictable, and dynamic
• Three key principles
• Adaptive rather than predictive
• Emphasize people rather than roles
• Self-adaptive processes
7
Agile Methodology
Agile Framework
Agile framework: SCRUM
Object-Oriented Analysis and Design (OOAD)
• Based on objects rather than data or processes
• Object: a structure encapsulating attributes and
behaviors of a real-world entity
• Object class: a logical grouping of objects sharing the
same attributes and behaviors
• Inheritance: hierarchical arrangement of classes
enable subclasses to inherit properties of superclasses
11
Rational Unified Process (RUP)
• An object-oriented systems development methodology
• RUP establishes four phase of development: inception, elaboration,
construction, and transition.
• Each phase is organized into a number of separate iterations.
12
Requirements
• Eliciting Requirements
• Expressing Requirements
• Prioritizing Requirements
• Analyzing Requirements
• Managing Requirements
• Eliciting vs Gathering
• Right product and product done right
Requirements
• Requirements are specific descriptions of your client's
needs
• Of the following, which would you consider software
requirements?
A. As a hotel manager, I want to be able to check guests in.
B. I'm required to make you sign a contract.
C. Account holders will enter their banking pin into a numeric
keypad
D. Users are male?
Requirements
• You have a big list of requirements for your client needs.
What's next?
• In Scrum, what is the step which happens after
requirements have been elicited and expressed from the
client and placed in a large list, also known as a product
backlog?
A. Development,
B. Requirements prioritization,
C. Product architecture design,
D. Further requirements elicitation.
Requirements
Requirements
• Business Requirements
Business requirements outline the purpose of a software
project. They give the product owners a reason to pursue the
project in the first place. ”Why” product is needed?
A business requirement must define product needs that
provide tangible and quantifiable business value. An example
of a business requirement is, I need this product to appeal to
clothing designers in India to raise our revenue by $50,000 per
year.
Requirements
• Business Rule
Business rules constrain how the product functions. They also specify
rules that need to be followed in order for the project to be considered
successful, or even appropriate.
• A privacy policy where the business requires data be stored securely
and not shared with non essential personnel.
• A brand uniformity requirement where the products to be developed
must be visually consistent with other products owned by the client.
• A government regulation such as a requirement to maintain user
data, and any information regarding its manipulation for a specific
period of time according to local or international laws.
User Requirements
• User requirements outline exactly what tasks the users can do with the
product. Users are those individuals who will end up using your
software. Since end users are so critical to a product's success, a great
deal of time is usually spent developing these requirements. These can
be thought of as the core functionality of the product being developed.
• Use Cases are a good way to show the relationship between the system
and the user. We're specifically showing the different user stories and
the ways in which they can interact with the system
• User Stories should be created so that one can better express client's
requirements
As a _____ I want to ______ so that _______. They follow this form so that
we can make sure we capture the who, what, and why of the requirement.
User Requirement
• After 3 unsuccessful login attempts by user, user should be locked out
• User interface should be menu driven providing dialog boxes, radio
buttons, help screens, dropdown list boxes for user inputs
Functional Requirement
• A functional requirement is a behavior that the product should do or support. They
can be expressed with inputs and outputs and a description of the behavior itself.
• Imagine a client wants a mobile point of sale product, which takes credit card
payments through the client's proprietary credit card reader. It then sends a
receipt back to the user with the transaction details.
• We have one input, the data from the credit card reader, and one output, the
receipt from the transaction. So you could say the system must read data from the
credit card reader and the system must also send a transaction receipt to the end
user.
• A functional requirement, which states that a user should be able to pay using a
PIN pad, is not specific. This could be broken into a few deeper, more specific
requirements, like a user should be able to swipe a debit or credit card. A user will
be able to insert a credit card or debit card into a chip reader. And a user will be
able to enter their PIN when their card has been swiped or inserted.
Functional Requirement
1.The system shall allow employees to view the owner of any product.
An employee should be able to contact the correct owner in one phone
call x% of the time.
2.The system shall send a verification mail to a user registering for the
first time to the shopping site
3.The system should be integrated with Banking API
Non-Functional Requirement
• The client also mentions that this product should meet the highest standards
of security as well as visual design. That last part about the product meeting
the highest standards of security, as well as visual design, are what we call
Non-Functional Requirements
• Non-Functional Requirements serve as a description of how well a product
must perform. Non-Functional Requirements really address the quality factor
of the product.
• Security requirements
• Error prevention or Reliability
• Ease of use or navigation
• Performance requirement like response time
• Maintainability
External Interfaces
• Connect with other components of the system
• External interfaces, physical product setting, and
development constraints.
• Which devices or platforms the development team will
support, or how much memory, bandwidth, or processing
power they're limited to using
* Acknowledgement: Coursera Software Product Management
Performing Requirements Determination
25
The Process of Determining Requirements
• Good Systems Analyst Characteristics:
• Impertinence—question everything
• Impartiality—consider all issues to find the best
organizational solution
• Relaxing constraints—assume anything is possible
• Attention to details—every fact must fit
• Reframing—challenge yourself to new ways
26
Deliverables and Outcomes
• Deliverables for Requirements Determination:
• From interviews and observations —interview transcripts,
observation notes, meeting minutes
• From existing written documents — mission and strategy
statements, business forms, procedure manuals, job descriptions,
training manuals, system documentation, flowcharts
• From computerized sources — Joint Application Design session
results, CASE repositories, reports from existing systems, displays
and reports from system prototype
27
Traditional Methods for Determining Requirements
• Interviewing individuals
• Interviewing groups
• Observing workers
• Studying business documents
• Group Techniques
• NGT
• Brainstorming
• Focus Groups
28
Guidelines for Effective Interviewing
• Interview Guide is a document for developing, planning and
conducting an interview.
• Plan the interview.
• Prepare interviewee: appointment, priming questions.
• Prepare agenda, checklist, questions.
• Listen carefully and take notes (record if permitted).
• Review notes within 48 hours.
• Be neutral.
• Seek diverse views.
29
Interviewing and Listening (Cont.)
Typical interview guide
30
Choosing Interview Questions
• Each question in an interview guide can include both verbal and non-
verbal information.
• Open-ended questions: questions that have no prespecified answers
• Closed-ended questions: questions that ask those responding to choose from
among a set of specified responses
31
Interviewing Groups
• Drawbacks to individual interviews:
• Contradictions and inconsistencies between interviewees
• Follow-up discussions are time consuming
• New interviews may reveal new questions that require additional interviews with
those interviewed earlier
• Interviewing several key people together
• Advantages
• More effective use of time
• Can hear agreements and disagreements at once
• Opportunity for synergies
• Disadvantages
• More difficult to schedule than individual interviews
32
Nominal Group Technique (NGT)
• A facilitated process that supports idea generation by groups
• Process
• Members come together as a group, but initially work separately.
• Each person writes ideas.
• Facilitator reads ideas out loud, and they are written on a blackboard or
flipchart.
• Group openly discusses the ideas for clarification.
• Ideas are prioritized, combined, selected, reduced.
• NGT exercise used to complement group meetings or as part of JAD
effort.
33
Directly Observing Users
• Direct Observation
• Watching users do their jobs
• Obtaining more firsthand and objective measures of employee interaction
with information systems
• Can cause people to change their normal operating behavior
• Time-consuming and limited time to observe
34
Analyzing Procedures and Other Documents
• Document Analysis
• Review of existing business documents
• Can give a historical and “formal” view of system requirements
• Useful document: Written work procedure
• For an individual or work group
• Describes how a particular job or task is performed
• Includes data and information used and created in the process
35
Analyzing Procedures and Other Documents
• Types of information to be discovered:
• Problems with existing system
• Opportunity to meet new need
• Organizational direction
• Names of key individuals
• Values of organization
• Special information processing circumstances
• Reasons for current system design
• Rules for processing data
36
Contemporary Methods for Determining System
Requirements
• Joint Application Design (JAD)
• Group Support
Brainstorming
Focus Group
• CASE tools
• Used to analyze existing systems
• Help discover requirements to meet changing business conditions
• System prototypes (RAD)
• Iterative development process
• Rudimentary working version of system is built
• Refine understanding of system requirements in concrete terms
37
Joint Application Design (JAD)
• Intensive group-oriented requirements determination technique
• Team members meet in isolation for an extended period of time
• Highly focused
• Resource intensive
• Upper CASE Tools used for documentation
38
JAD (Cont.)
Illustration of the typical room layout for a JAD
Source: Based on Wood and Silver, 1995
39
JAD (Cont.)
• JAD Participants:
• Session Leader: facilitates group process
• Users: active, speaking participants
• Managers: active, speaking participants
• Sponsor: high-level champion, limited participation
• Systems Analysts: should mostly listen
• Scribe: record session activities
• IS Staff: should mostly listen
• End Result
• Documentation detailing existing system
• Features of proposed system
40
Prototyping During Requirements
Determination
• Rapid Application Development: Quickly converts
requirements to working version of system
• Once the user sees requirements converted to system, will
ask for modifications or will generate additional requests
• Most useful when:
• User requests are not clear.
• Few users are involved in the system.
• Designs are complex and require concrete form.
• There is a history of communication problems between analysts and users.
• Tools are readily available to build prototype
41
Prototyping During Requirements Determination
• Drawbacks
• Tendency to avoid formal documentation
• Difficult to adapt to more general user audience
• Sharing data with other systems is often not considered
• Systems Development Life Cycle (SDLC) checks are often bypassed
• Prototype may be discarded
42
Radical Methods for Determining System
Requirements
• Business Process Reengineering (BPR): search for and implementation of radical
change in business processes to achieve breakthrough improvements in products
and services
• Goals
• Reorganize complete flow of data in major sections of an organization.
• Eliminate unnecessary steps.
• Combine steps.
• Become more responsive to future change.
• Identification of processes to reengineer
• Key business processes
• Structured, measured set of activities designed to produce specific output for a particular customer or market
• Focused on customers and outcome
43
Requirements Determination using Agile
Methodologies
• Continual user involvement
• Replace traditional SDLC waterfall with iterative analyze – design – code – test
cycle
• Agile usage-centered design
• Focuses on user goals, roles, and tasks
• The Planning Game
• Based on eXtreme programming
• Exploration, steering, commitment
44
Agile Usage-Centered Design Steps
• Gather group of programmers, analysts, users, testers, facilitator.
• Document complaints of current system.
• Determine important user roles.
• Determine, prioritize, and describe tasks for each user role.
• Group similar tasks into interaction contexts.
• Associate each interaction context with a user interface for the system and
prototype the interaction context.
• Step through and modify the prototype.
45
The Planning Game from eXtreme
Programming
eXtreme Programming’s Planning Game
46
