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.