Requirements
 |
Are SMART Goals Smart Enough? A common way of approaching business and project goal setting is to use the SMART technique (Specific, Measurable, Achievable, Realistic, and Time-bounded), but is it smart enough? Adrian Reed explores a personal goal setting technique, PECSAW, to attempt to answer that question. |
|
 |
How (and Why) You Should Split User Stories The Scrum process is built around the process of implementing user stories. Many teams struggle with the challenge of knowing how to split user stories so that the individual stories have atomic value and are properly sized. |
|
 |
Care about Your Business? Then Care about Your Projects! The distinction between project failure and business failure is slight—one can very easily lead to the other. One way to help avoid the downstream issues on any project is to ensure that sufficient project management and business analysis resources are assigned. |
|
 |
How to Start a Business Model Canvas The business model canvas is an informal presentation of a formalized description of why a business will succeed, built around the value proposition of the business. We explore the core of the canvas, examine the value proposition, and provide tips on how to start a business model canvas. |
|
 |
What Is a Requirement? When considering the various definitions of the term "requirement" and the application of each, it is equally important to have a definition in mind that can be easily recalled and referenced. |
|
 |
Tips for Starting (and Ending) a Process Analysis Without boundaries, a process analysis could go on forever. Adapting things learned from working in agile software development, Scott Sehlhorst provides tips for starting—and ending—a process analysis. |
|
 |
Bug or New Requirement – Does It Matter? The terms "bugs" and "requirements" indicate who is responsible for the problem. No matter which term is used for the current state, the current state needs to change. Only then can the focus shift to fixing the problem. |
|
 |
Debate: The Danger of "Negative" Requirements Is it advisable to define a system by stating what it shouldn’t do, or should “negatively-framed” requirements be avoided? |
