Introduction to Requirements Lisa Komidar, SCM/CAPM PSU World Campus – Learning Design lmd5@psu.edu http://lisakomidar.com

Poor Requirements = Project Failure According to Wrike.com, 38% of project failures is due to poor requirements. Effects of poor or lack of requirements Knowledge of testing needs Flawed design Missing user needs Poor quality Late delivery Can you name a few? 2

Attributes for good requirements Complete - they very thoroughly describe the criteria Correct - they are accurate and true Feasible - they can be accomplished and individual requirements do not contradict each other. Necessary - they are truly needed for the system to function properly and they are really what the client wants. Prioritized - in the case that not all parts of the system can be implemented at the same time, it's important to be able to distinguish "absolutely necessary" from "nice to have". Unambiguous - they are clear and cannot be misinterpreted Verifiable - once implemented, it can be confirmed that the system has met the requirement through observation and testing 3

Three types of poor requirements Missing Irrelevant Bad

Impacts of poor requirements Scope creep negatively affecting budget and completion time Low utilization of resources and higher overheads Inadequate business process design (due to insufficient details about activities) Poor design and ergonomics of the user interface, resulting in lower productivity Inadequate software specification, resulting in lower developer productivity Poor specification amplifies the negative effect of poor requirements when it comes to software testing, leading to higher costs and lower quality of the solution Time-consuming and costly code rework Difficulties in solution integration. 5

IT Pain Brad Matsugu, 2012

Where to start ​Understand the business need using the project charter Analyze the gaps as defined in the scope statement Understand functional vs. non-functional Functional tasks the software must perform scope of the system product boundaries connections to adjacent systems business rules Non-Functional look and feel operating environment cultural, legal and political issues 7

Where to really start Domain Experts - people who are very knowledgeable and work in the area of the system that is being built Users - people who will actually be the ones using the system once it's built Find out the limitations of existing systems and software Find out where the users' time is spent Find out what they like and don't like User shadowing Review similar software programs 8

Different techniques One-on-one interviews Group interviews Facilitated sessions Questionnaires Prototyping Use cases Brainstorming 9

One on one interview Planned ahead Open ended questions Probing questions Walk through example 10

Group interview Two to four people Typically same level or role Must keep the group focused Walk through example 11

Facilitated session Five or more users Faster approach to get a common set of requirements Allow for a longer time Walk through example 12

Questionnaires A good way to get information from remote users Typically covers a large number of users who will have minor input Much more informal 13

Prototyping A more modern approach Prototype built on preliminary requirements Show this to client Modify prototype based on feedback Circle back until product meets business needs 14

Use cases Also known as user stories As <user>, I want to <action> so I can <result> Defines a definition of done Walk through example 15

Brainstorming Set aside a longer period of time All users together Tools Whiteboards Stickies Online collaboration such as box notes or google docs Generate ideas Prioritize Agreement Walk through example 16

Combining Brainstorming, User stories, prototyping Allow for a longer period of time to be able to capture all requirements What you give up front will save you in the end! Full project team Stakeholders Developers UX Design Accessibility Start at a higher level and work down to fine details For larger projects, start with high requirements and break them out into your phases. Then applying an agile approach, work on a single phase. Walk through! 17