1. Analyzing the Problem Continued and Product Features and Challenges Steve Chenoweth & Chandan Rupakheti RHIT Pages 52-100 Requirements Text

2. The Five Steps in Problem Analysis 1.Identify the stakeholders 2.Gain agreement on the problem 3.Understand the root causes 4.Define the solution system boundary 5.Identify the constraints imposed on the solution

3. Step 4: Define Boundaries “define the boundary between the solution and the real world”  Draw a picture: Solution system is a black box in the middle of the picture Users of the software are shown Systems that interact with the solution are also shown Users and interacting systems are collectively known as “Actors”

4. Some Questions to ask  Who will supply, use or remove information from the system?  Who will operate the system?  Who will perform system maintenance?  Where will the system be used?  Where does the system get its information?  What other external systems will interact with this system?

5. 5 The Five Steps in Problem Analysis 1.Identify the stakeholders 2.Gain agreement on the problem 3.Understand the root causes 4.Define the solution system boundary 5.Identify the constraints imposed on the solution

6. Step 5: Identify Constraints “ A restriction on the degree of freedom we have in providing a solution” Frequently-Used Constraint Classifications Economics Politics Technology Existing Systems Environment Schedule and Resources

7. A Team Exercise – We’ll Do It During Class  See quiz question on this - to write some answers ahead of time!  On the board… Identify actors for the degree planner system. What are some known or likely constraints for this system?

8. Two Domain-Specific Problem Analysis Techniques  Business Modeling Information Systems/IT domain  Systems Engineering Embedded systems domain

9. Barriers to Elicitation 1. Not getting to the people who have knowledge of value to you... Cartoon from http://www.dmst.aueb.gr/dds/etech/swdev/elicit.htm.http://www.dmst.aueb.gr/dds/etech/swdev/elicit.htm

10. Three Common Barriers  “Yes, But…” Syndrome Develop techniques to get rid of the “But” early.  Undiscovered Ruins Syndrome “the more you find, the more you know remain” --> find the right balance  User and Developer Syndrome Communication gap between the users.

11. Needs  Each stakeholder will have needs that will hopefully be addressed by the new system Example: “I want to be able to advise my students more effectively.”  Needs are often ambiguous  Users may neither describe their need (Why this product is necessary) nor do they describe the requirement (What this product needs to do) “They are more abstract”

12. Feature  A feature is a service that the system provides to fulfill one or more stakeholder needs. Example: “This tool will allow the advisor to see the critical path in an advisee’s coursework.”  Look for needs that suggest features  When users talk about features or in other high level abstracts, make sure you understand the real need behind the requested feature.

13. Feature  Attributes to describe a feature Status Priority Effort Risk Stability Target release Assigned to Reason

14. Another Team Exercise  See quiz question on this - to write some answers ahead of time!  As a team try to identify some features for the degree planner project. (See Tuesday’s ppt, Slide 7 notes.)  Then, see if you can prioritize these – what are the three most important (in your team’s opinion)?  If there’s time, we’ll put our answers on the board, and compare.