I494: Designing and Developing an Information System Week 7 October 7, 2013

Please sit together with your team today

Outline Admin Requirements

Practice on Wednesday Keep an eye on your email about where to go on Wednesday! Practice activities this week: Start figuring out exactly what features/functionality your project will contain Start gathering requirements!

Upcoming Assignments Team Project Proposal Due Tuesday, September 24th by 5pm Team Project Research Report Due Tuesday, October 1st by noon One submission per team Team Prioritized Feature List Due Tuesday, October 8th by 5pm Team Basic Use Case List Due Tuesday, October 15th by 5pm Tomorrow! Next Week

Research Paper Rubric Research: 50% Style: 20% Risks: 10% Feasibility/Platform/Client/Business Case: 20%

Research Paper Rubric Research: 50% Style: 20% Risks: 10% Feasibility/Platform/Client/Business Case: 20% Issues: Little or no cited sources to back up claims Failure to compare competing technologies Failure to choose and defend a platform

MidTerm Exam Monday, October 21 During normal class time 4-5:15pm in SW119

Jeff Astrove John Deere Business Analyst, SAP Global Trade Services BS, Informatics 2008 MSIS 2009

Mark Kasten Accenture Senior Manager BS 1997, Kelley

Requirements

Capstone Mantra “Plan the work, then work the plan”

What are Requirements? As complete a plan for building your system as it is feasible to create! More time spent gathering and specifying requirements results in much less time spent developing and testing. 40-60% of all defects in software products can be directly attributed to errors in the requirements phase.

Types of Requirements Functional Specifies the software functionality that must be built “The system must…” Often grouped around features NonFunctional Quality attributes “user-friendly” Constraints Performance goals Business rules

Requirements Business Requirements High-level objectives of the client Why the system is being built Vision and scope document User Requirements Defines user goals or tasks Business rules Not a software requirement per se, but impacts requirements Regulations, policies, etc

Requirements Qualitative vs Quantitative

Requirements Lifecycle Elicitation Analysis Specification Verification

Ways to Elicit Requirements

Ways to Elicit Requirements Interviews Observation Study the “As is” situation Surveys Research Prototype Brainstorming

“ilities” Usability Maintainability Flexibility Testability Scalability Availability Extensibility Security Portability Compatibility Backwards Compatibility Interoperability Reusability Quality Marketability Configurability Auditability

Kinds of Requirements Exciting Over the top ideas Regular Standard ideas Expected Unstated ideas

Excellence in Requirements What qualities should describe your requirements?

Excellence in Requirements Complete Correct Feasible Necessary Prioritized Unambiguous Verifiable

Complete Requirements Fully describes functionality Contains all information to design and build Use placeholders (templates) Example: The system must capture customer information The system must capture name, address, phone number and email information for customers

Correct Requirements Strive for total accuracy Users are critical in determining correctness

Feasible Requirements Can it be built? Do you have the skills to build it?

Necessary Requirements Actual need Legal compliance Traced to origin Understand why functionality is required

Prioritized Requirements Rank High, medium low Trace How are functions related? Provides flexibility for schedule adjustments, new requirements, etc.

Unambiguous Requirements Two person test: Randomly choose two people – Do they agree on interpretation Natural language can be problematic Use the user’s language – not jargon Define any specialized terms Simple, concise, straightforward language

Verifiable Requirements Develop test scenarios in advance

Exit Strategy All projects need an exit strategy In other words, plan for completion Might be contractually defined

Version Management Consider the lifecycle of the requirements Do you change them? Is there a document for each change? What about the schedule? Changes have ripple effects

Requirements Organization How should we label the requirements By name? By number? By category?

Strategy Work from high level to details Use diagrams to communicate ideas Build a dictionary Users have a different language Use html documents for navigation

Tool: Use Cases Allows a team to elicit requirements by analyzing a sequence of interactions between a user role and the system. Objective is to describe all tasks that any user role will need to perform within the system.

Use Cases Work from low level of detail to high level of detail Step 1: Number and Name Step 2: low detail Step 3: high detail

Example 1 An online order process

Step 1: Use Case Number: 1.0 Use Case Name: Place Order

Step 2: “Casual” Use Case Use Case Number: 1.0 Use Case Name: Place Order Use Case Description: After the user has selected items to order, the user will give payment information and shipping location. When the order is placed a confirmation will be given to the user. Some users will have existing accounts.

Step 3: Full Use Case Use Case Number: 1.0 Use Case Name: Place Order Actors: Registered user Non-registered user Order system Billing system Triggers: The user is done shopping and indicates that they want to checkout. Precondition: User has selected items to purchase Post conditions: Order will be placed in system The user will have a confirmation

Step 3: Use Case Number: 1.0 Use Case Name: Place Order Normal flow: 1: The user indicates they want to checkout 2: The order system will show previous billing and shipping information 3: The user confirms billing and shipping 4: The order system shows the total cost 5: The user confirms the order 6: The order system will provide details to the billing system 7: The billing system will verify payment information and report back approval status 8: The order system will provide an order confirmation Alternate flows: 3.A.1: The user enters alternate billing and/or shipping information 5.A.1: The user cancels the order 8.A.1: The order system will provide a disapproved order confirmation

Classroom Assessment This is NOT graded! Get out a piece of paper and take a few moments to write down the answer to the following question: What was the most surprising point from today’s class for you? Make sure you write your name on the paper and turn it in as you leave class.