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

2. Please sit together with your team today

3. Outline
Admin Requirements

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

5. 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

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

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

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

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

10. Mark Kasten
Accenture Senior Manager BS 1997, Kelley

11. Requirements

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

13. 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 % of all defects in software products can be directly attributed to errors in the requirements phase.

14. 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

15. 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

16. Requirements
Qualitative vs Quantitative

17. Requirements Lifecycle
Elicitation
Analysis
Specification
Verification

18. Ways to Elicit Requirements

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

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

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

22. Excellence in Requirements
What qualities should describe your requirements?

23. Excellence in Requirements
Complete Correct Feasible Necessary Prioritized Unambiguous Verifiable

24. 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 information for customers

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

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

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

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

29. 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

30. Verifiable Requirements
Develop test scenarios in advance

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

32. 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

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

34. 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

35. 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.

36. 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

37. Example 1
An online order process

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

39. 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.

40. 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

41. 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

42. 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.