1 sys366 week 5 - lecture 1 systems requirements gathering: identifying software requirements
Post on 17-Jan-2016
217 Views
Preview:
TRANSCRIPT
1
SYS366
Week 5 - Lecture 1Systems Requirements Gathering:
Identifying Software Requirements
2
Agenda
Identifying Software Requirements – Functional Requirements– Technical Requirements– Data Requirements
Fact Finding Methods
3
Identifying Requirements
Objective of the requirements capture and analysis phases is to understand business processes and develop requirements for the new system
4
5
Identifying System Requirements
“A requirement is a desired feature, property or behavior of a system.” *
* Unified Modeling Language
6
7
Identifying System Requirements
“Features can be functional or
non-functional.” *
* Use Case Modeling, by Bittner & Spence, page 75.
8
Identifying System Requirements
Software Requirements – “Individual statements of conditions and capabilities
to which the system must conform.” *
* Use Case Modeling, by Bittner & Spence, page 6.
9
Identifying System Requirements
Each Software Requirement Is the specification of an externally observable behavior of the system– Inputs to the system– Outputs from the system– The processing of the system– Attributes of the system– Attributes of the system environment
Use Case Modeling, by Bittner & Spence, page 5.
10
What is Software Development?
Software Development implies developing some software – but it does not involve simply coding programs
Software is developed to turn manual processes into automated processes or to improve/enhance existing automated processes.
11
What does this have to do with Systems?
Software Development entails understanding the problem to be solved, understanding how a business operates and understanding that the solution to be developed will be of value to the business
12
Identifying System Requirements
“Software Requirements specify the things that the software does on behalf of the user or another
system.” *
* Use Case Modeling, by Bittner & Spence, page 6.
13
Requirements Gathering
Analyst needs to find out what the user requires in the new system or what the user requires to be changed in an existing system– Gather the requirements by doing fact finding– Document the requirements
14
Requirements Gathering
For an existing system, analyst needs to find out:– Functionality
Some of the functionality of the existing system will be included in the new system (can be acquired from existing documentation and code)
– Data needs Some of the data of the existing system will need
to be migrated into the new system
15
Requirements Gathering
For a new system, analyst needs to find out:– Functionality
What are the activities the system needs to perform?
How is the user to interact with the system?Are other systems to interact with the system?
– Data needsWhat information is needed?
16
Requirements Gathering
Scope of the System
Functional Technical DataRequirements Requirements Requirements
17
Functional Requirements
Describe what a system does or is expected to do “Specify the input and output behavior of a system”*
*Use Case Modeling, by Bittner & Spence, page 8.
18
Functional Requirements
Include– Descriptions of the processing which the system will be
required to carry out– Details of the inputs into the system from paper forms
and documents or the interactions between people and the system or transfers from other systems
– Details of the outputs that are expected from the system in the form of printed documents and reports, screen displays and transfers to other systems
:
19
Technical Requirements
“Specify the other qualities that the system must have, such as those related to the usability, reliability, performance and supportability of the system”*
Describe the aspects of the system that are concerned with how well it provides the functional requirements.
Include:– Performance criteria– Anticipated volumes of data– Security requirements
*Use Case Modeling, by Bittner & Spence, page 8.
20
Data Requirements
Describe what information the system is going to need or produce – really a part of Functional and Technical Requirements
Include– Details of the data that must be held in the system
21
Themes To Guide Investigation
What are business processes and operations? How should the business processes be performed? What are the information requirements?
Understand the Users’ Needs!
22
Today
Identifying System Requirements – Functional Requirements– Technical Requirements– Data Requirements
Fact Finding Methods
23
Fact Finding Methods
Conduct interviews and discussion with users Distribute and collect stakeholder questionnaires Review existing reports, forms, and procedure
descriptions Observe business processes and workflows Build prototypes Conduct JAD sessions
24
Fact Finding Methods
– Interviews– Questionnaires– Review Documentation– Observation– Prototypes– JAD sessions– RAD
25
Interviews
We are going to concentrate on interview techniques; the rest of the slides explain the other methods for fact finding
26
Interviews
Primary technique for fact finding and information gathering
Most effective way to understand business functions and business rules
Usually requires multiple sessions Usually conducted with customers/clients/users Clients are not always able to express their
requirements clearly it is up to the analyst to ask the right questions to help the client express their requirements
27
Conducting effective interviews
– Determine who you are going to interview– Know what information that stakeholder can provide
for you– Prepare for the interview– Conduct the interview– Follow up on the interview
28
Determine who you are going to interview
Can be business or technical stakeholders– Business stakeholders provide the functional and
data requirements– Technical stakeholders provide the technical and
data requirements
29
Determine who you are going to interview
Executives– Will provide information related to strategic issues
about the business – Need statistical and summary information
Management– Will provide a broad perspective about the business
as well as information about the system being developed
– Need statistical and summary information
30
Determine who you are going to interview
Operational staff – will provide information about how the work is
actually done– Domain experts
31
Types of interviews
Structured Interview– Formal style– Requires significant preparation
Unstructured Interview– Informal– No pre-determined questions or objectives
32
Structured Interview
Preparing for the interview– Establish the objectives for the interview– Have a clear agenda– Prepared in advance with a list of open and closed
ended questions– Set the time and location for the interview– Inform all participants of the objective, time and
location
33
Structured Interview
Questions– Questions should allow you to keep on track and
avoid getting off topic during the interview– Keep length of questions reasonable (15-20 words
or less)
34
Structured Interview
Questions can be prepared from any of the following:– Observations made when existing form and reports
may have been reviewed– Observations made when reviewing the strategic,
tactical or operational plans– Observations made when observing employees
doing current job tasks
35
Structured Interview
Phrase questions to avoid misunderstandings - use simple terms and wording
Do not ask questions that give clues to expected answers
Avoid asking two questions in one Do not ask questions that can raise concerns about job
security or other negative issues
36
Structured Interview
Questioning Strategies
How canorder processing
be improved?
How can wereduce the number
of times that customersreturn items they’ve ordered?
How can we eliminate shipping the wrong products?
High-level: very general
Medium-level: moderatelyspecific
Low-level: very specific
Top Down
Bottom UP
37
Structured Interview
Open ended questions– Encourages unstructured responses and generates discussion– Useful when you need to understand a larger process or to
draw out opinions or suggestions from the person being interviewed
– Examples What do you think about the current system? How do you decide what type of marketing campaigns to
run?
38
Structured Interview
Closed ended questions– Limited or restricted response – a simple definitive
answer– Used to get information that is more specific or
when you need to verify facts– Examples:
How do customers place orders?How many orders to you receive a day?
39
Structured Interview
How to conduct the interview– Dress appropriately; Arrive on time– Welcome the participants; introduce the attendees;
state the objective and agenda– Ask permission if you want to tape record the
interview– Ask questions from script
40
Structured Interview
How to conduct the interview– Listen closely to the interviewee and encourage
them to expand on key points– Take thorough notes– Identify and document unanswered questions– At end of interview, review outstanding questions
that require follow up– Set date and time for the next, follow-up interview
41
Fact Finding Methods
– Interviews– Questionnaires– Review Documentation– Observation– Prototypes– JAD sessions– RAD
42
Questionnaires
A document which contains a number of questions Can be paper form or electronic form (email or web-
based) Allows the analyst to collect information from a large
number of people– People outside the organization (I.e. customers)– Business users spread across a large geographic
area
43
Questionnaires
Limited and specific information from a large number of stakeholders
Preliminary insight Not well suited for gathering detailed information Open-ended questions vs. close-ended questions
44
Questionnaires
Similar process to interviewing– Determine who will receive the questionnaire– Design the questionnaire
Determine objective of questionnaire Design questions
– Follow up questionnaire
45
Questionnaires
Determine who will receive the questionnaire– Select a sample audience who are representative of
an entire group– Assume 30-50% return rate for paper and email
questionnaires– Assume a 5-30% return rate for web-based
questionnaires
46
Questionnaires
Design the Questionnaire– Clearly state the following in the questionnaire:
The purpose of the questionnaireWhy the respondent was selected to receive the
questionnaireWhen the questionnaire is to be returned
47
Questionnaires
Design the Questionnaire– Let the respondent know when/where they can see
the accumulated questionnaire responses– Consider providing an inducement to have the
respondent complete the questionnaire (I.e. a pen)
48
Questionnaires
Design the Questionnaire– Keep the questionnaire brief and user friendly– Provide clear instructions on how to complete the
questionnaire– Arrange the questions in a logical order; going from
easy to more complex topics
49
Questionnaires
Design the Questionnaire– Phrase questions to avoid misunderstandings, use
simple terms and wording– Do not ask questions that give clues to expected
answers– Avoid asking two questions in one– Limit the use of open ended questions that will be
difficult to tabulate
50
Questionnaires
Design the Questionnaire– Do not ask questions that can raise concerns about
job security or other negative issues– Include a section at the end of the questionnaire for
general comments– Test the questionnaire whenever possible on a
small test group before finalizing it
51
Fact Finding Methods
– Interviews– Questionnaires– Review Documentation– Observation– Prototypes– JAD sessions– RAD
52
Review Existing Reports, Forms, and Procedure Descriptions
Purposes– Preliminary understanding of processes– Guidelines / visual cues to guide interviews
Identify business rules, discrepancies, and redundancies
Be cautious of outdated material
53
Reviewing existing documentation
Most beneficial to new employees or consultants hired to work on a project
Types of documentation that is reviewed:– Company reports– Organization charts– Policy and Procedures manuals– Job Descriptions– Documentation of existing systems
54
Reviewing existing documentation
Allows the analyst to get an understanding of the organization prior to meeting with employees
Allows the analyst to prepare questions for either interviews or questionnaires (other fact finding techniques)
55
Fact Finding Methods
– Interviews– Questionnaires– Review Documentation– Observation– Prototypes– JAD sessions– RAD
56
Observation
An effective way to gather requirements if obtaining complete information was not effective through other fact finding techniques (I.e. interviews and questionnaires)
Or An effective way to verify information gathered from
other fact finding sources (such as interviews)
57
Observation
Observation can be done by having the analyst observe the client from a distance (without actually interrupting the client) or by actually doing the work of the client
58
Observation
Should be carried out for a period of time and at different time intervals, not just once, so that the analyst can observe different workloads and to ensure that what the client does is consistent over different periods of time
59
Observation
Allows the analyst to follow an entire process from start to finish
Can upset the client if they feel threatened by new activity going on around them – the client may behave differently from what they normally do
60
Fact Finding Methods
– Interviews– Questionnaires– Review Documentation– Observation– Prototypes– JAD sessions– RAD
61
Prototypes
A demonstration system– Represents a graphical user interface– Simulates system behavior for various events– Any data displayed on a GUI screen is hard-coded; not
retrieved from a database Constructed to visualize the system Allows the customer to provide feedback An effective way to gather requirements for a new
system Supports JAD or RAD type sessions
62
Fact Finding Methods
– Interviews– Questionnaires– Review Documentation– Observation– Prototypes– JAD sessions– RAD
63
Other Methods
Joint Application Development (JAD)– A series of workshops that bring together all
stakeholders (users and systems personnel)
64
Other Methods
Joint Application Development (JAD)– Consists of the following types of attendees:
Facilitator: the person who conducts the meeting and keeps it on track (generally the analyst)
Note taker: the person who records the information for the session
Clients/Customers/Users: the people who communicate the requirements, take decisions and approve the project
Developers: the people who are part of the development team and need to gather information
65
Other Methods
Joint Application Development (JAD)– Takes advantage of the group dynamics– Increased productivity– May require more than one session– One session may last a few hours, several days or
several weeks
66
Fact Finding Methods
– Interviews– Questionnaires– Review Documentation– Observation– Prototypes– JAD sessions– RAD
67
Other Methods
Rapid Application Development (RAD)– An approach to software development where the
system solution is delivered – fast– Most appropriate for systems which are not the
organization’s core business
68
Other Methods
Rapid Application Development (RAD)– Can result in:
Inconsistent GUI designsPoorly documented systemsSoftware that is difficult to maintain
top related