SYS366 Week 3, Lecture 2 Introduction to Requirements Gathering:

Name: SYS366 Week 3, Lecture 2 Introduction to Requirements Gathering:
Uploaded: 2017-08-18T13:02:47+00:00
Duration: PTM26S34
Channel: Timothy Singleton
Description: SYS366 Week 3, Lecture 2 Introduction to Requirements Gathering:

SYS366 Week 3, Lecture 2 Introduction to Requirements Gathering:
Part 2 – The Stakeholders’ Needs

Today Stakeholders Identifying System Requirements
Functional Requirements Technical Requirements Data Requirements Fact Finding Methods Interview Questions WP1

Categories of Stakeholders
Five primary categories Users Sponsors Developers Authorities Customers

Questions to Ask to Determine Stakeholders:
Who will be affected by the success or failure of the new solution? Who are the users of the system? Who is the economic buyer for the system? Who is the sponsor of the development? * * Use Case Modeling, by Bittner & Spence, page 63.

Who else will be affected by the outputs that the system produces? Who will evaluate and sign off on the system when it is delivered and deployed? Are there any other internal or external users of the system whose needs must be addressed? * * Use Case Modeling, by Bittner & Spence, page 63.

Are there any regulatory bodies or standards organizations to which the system must comply? Who will develop the system? Who will install and maintain the new system? Who will support and supply training for the new system? Who will test and certify the new system? * * Use Case Modeling, by Bittner & Spence, pages

Who will sell and market the new system? Is there anyone else? Okay, Is there anyone else? * * Use Case Modeling, by Bittner & Spence, page 64.

Back to In-class exercise 5
Using In-class exercise 4 and the list of business processes for your area, update In-class exercise 5 to include more stakeholders

Identifying System Requirements
Objective of the requirements capture and analysis phases is to understand business processes and develop requirements for the new system

“A requirement is a desired feature, property or behavior of a system.” * * Unified Modeling Language

A requirement “is either derived directly from stakeholder or user needs Or stated in a contract, standard, specification, or other formally imposed document.” * * Use Case Modeling, by Bittner & Spence, page 5.

Stakeholder Need: A reflection of the business, personal or operational problem…that must be addressed to justify consideration, purchase or use of the new system. * * Use Case Modeling, by Bittner & Spence, page 72.

Capturing stakeholder needs allows us to understand how and to what extent the different aspects of the problem affect different [categories] of stakeholders. * * Use Case Modeling, by Bittner & Spence, page 72.

Stakeholder needs are an expression of the true ‘business requirements’ of the system * * Use Case Modeling, by Bittner & Spence, page 72.

Stakeholders’ Needs Back to In-class Exercise 5 to identify Stakeholders’ needs!

Features: “Informal statements of capabilities of the system used often for marketing and product-positioning purposes as a shorthand for a set of behaviors of the system.” Use Case Modeling, by Bittner & Spence, pages

Features: “The high-level capabilities (services or qualities) of the system that are necessary to deliver benefits to the users and that help to fulfill the stakeholders and user needs.” * * Use Case Modeling, by Bittner & Spence, page 74.

“Features can be functional or non-functional.” * * Use Case Modeling, by Bittner & Spence, page 75.

“Features represent some area of functionality of the system that, at this time, is important to the users of the system” * * Use Case Modeling, by Bittner & Spence, page 75.

“The immediate and informal nature of features makes them a very powerful tool when working with the stakeholders and customers in defining what they want from a system’s release.” * * Use Case Modeling, by Bittner & Spence, page 76.

“Features provide the fundamental basis for product definition and scope management” * * Use Case Modeling, by Bittner & Spence, page 76.

Software Requirements “Individual statements of conditions and capabilities to which the system must conform.” Use Case Modeling, by Bittner & Spence, page 5. Page 6

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. Page 6

Software Requirements specify the things that the software does on behalf of the user or another system. Use Case Modeling, by Bittner & Spence, page 5. Page 6

Successful Project Requirements
Detailed plans Organized, methodical sequence of tasks and activities

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

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

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 needs What information is needed?

Scope of the System Functional Technical Data Requirements Requirements Requirements

Functional Requirements
Describe what a system does or is expected to do Include: Descriptions of the processing which the system will be required to carry out

Functional Requirements
Include: 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

Technical Requirements
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 (let’s talk about the Bank of Montreal!)

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

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!

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

Fact Finding Methods Interviews Questionnaires Review Documentation
Observation Prototypes JAD sessions RAD

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

Interviews We are going to concentrate on interview techniques; the rest of the slides explain the other methods for fact finding

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

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

Stakeholders 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

Stakeholders Operational staff will provide information about how the work is actually done

Prepare for the interview
Structured Interview Formal style Requires significant preparation Unstructured Interview Informal No pre-determined questions or objectives

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

Structured Interview Questions
Questions should allow you to keep on track and avoid getting off topic during the 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 Keep length of questions reasonable (15-20 words or less)

Structured Interview Questions
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

Structured Interview Questioning Strategies Top Down How can
order processing be improved? How can we reduce the number of times that customers return items they’ve ordered? How can we eliminate shipping the wrong products? High-level: very general Medium-level: moderately specific Bottom UP Low-level: very specific

Structured Interview Questions 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

Structured Interview Questions 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

Structured Interview Sample interview questions Open-ended
What do you think about the current system? How do you decide what type of marketing campaigns to run? Closed-ended How do customers place orders? How many orders to you receive a day?

Structured Interview 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 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

WP1 Requirements for WP1

Questionnaires A document which contains a number of questions
Can be paper form or electronic form ( 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

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

Questionnaires Similar process to interviewing
Determine who will receive the questionnaire Design the questionnaire Determine objective of questionnaire Design questions Follow up questionnaire

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 questionnaires Assume a 5-30% return rate for web-based questionnaires

Questionnaires Design the Questionnaire
Clearly state the following in the questionnaire: The purpose of the questionnaire Why the respondent was selected to receive the questionnaire When the questionnaire is to be returned

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)

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

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

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

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

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

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)

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)

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

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

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

Prototypes A demonstration system Constructed to visualize the 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

Other Methods Joint Application Development (JAD)
A series of workshops that bring together all stakeholders (users and systems personnel)

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

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

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

Other Methods Rapid Application Development (RAD) Can result in:
Inconsistent GUI designs Poorly documented systems Software that is difficult to maintain

SYS366 Week 3, Lecture 2 Introduction to Requirements Gathering:

Similar presentations

Presentation on theme: "SYS366 Week 3, Lecture 2 Introduction to Requirements Gathering:"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

SYS366 Week 3, Lecture 2 Introduction to Requirements Gathering:

Similar presentations

Presentation on theme: "SYS366 Week 3, Lecture 2 Introduction to Requirements Gathering:"— Presentation transcript:

Similar presentations

About project

Feedback