SOFTWARE REQUIREMENTS: WHAT, WHY, AND WHO

SOFTWARE REQUIREMENTS: WHAT, WHY, AND WHO

1. The essential software requeriment

   • It can be derived in my types, and the developer's notion can be different of the costumers. So there can be confusion.
     • Some interpretations of 'requirement':
       • A good definition is “anything that drives design choices” by Lawrence, and this requirement is not the same term of the diccionary (Something obligatory).
     • Working with the three levels:
       • Different organizations use a variety of name for the roles involved, it depends of the developing organization. These are: Buisness requirement, User requirement, Funcional Requirement.
     • Product vs project requirements
       • Project requirements are things that are not part of the software, but are necessary for the completion of the project.
       • Product requirements are what describes properties of a software system to be built (What we being talking previously).
   • Requirements development and management:
     • Requirements development: These subdisciplines encompass all the activities involved with exploring, evaluating, documenting, and confirming the requirements for a product.
       • Elicitation: All of the activities involved with discovering requirements.
       • Specification: Storing the collected requirements knowledge in a persistent and well-organized fashion.
       • Analysis: Analyzing requirements involves reaching a richer and more precise understanding of each requirement
       • Validation: Confirms that you have the correct set of requirements, to satisfies the business objectives.
   • Every project has requirements:
     • Every project team has to has representations of requirements written, this to please as much as posible the skateholders.
   • When bad requirements happen to good people:
     • Rework is the main requirement problems, it consumes 30 to 50 procent of the total develoment cost.
       • Inaccurate planning:
         • Vague, poorly understood requirements lead to overly optimistic estimates, which come back to haunt you when the inevitable overrun
       • Crepping user requirements:
         • As requirements evolve during development, projects often exceed their planned schedules and budgets.
       • Ambiguous requirements:
         • One sign of this is that multiple readers of a requirement arrive at different understandings of what it means.
       • Gold plating:
         • Happens when functionality that wasn’t in the requirements specification are added, because the developer believes “the users are just going to love.”
       • Overlooked stakeholders:
         • If you don't identify the important user classes for your product early on, some user needs won't be met.
   • Benefits from a high-quality requirements process:
     • -Fewer defects in requirements and in the delivered product.
     • -Reduced development rework.
     • -Faster development and delivery.

2. Requirement from the customer's perspective

   • The Expectation Gap
     • A gulf between what customers really need and what developers deliver based on what they heard at the beginning of the project.
   • Who is the Customer?
     • customer is an individual or organization that derives either direct or indirect benefit from a product.
   • The Customer-Development Partnership
     • A collaborative effort can work only when all parties involved know what they need to be successful and when they understand and respect what their collaborators need to be successful.
       • Requirements Bill of Responsibilities for Software Customers
         • Some resposabilities
           • To educate BAs and developers about your business
           • To dedicate the time that it takes to provide and clarify
           • To be specific and precise when providing input about requirements
     • Requirements Bill of Rights for Software Customers
       • Some rights
         • To expect BAs to speak your language
         • To expect BAs to learn about your business and your objectives
         • To expect BAs to learn about your business and your objectives
   • Creating a culture that respects requirements
     • Show people how their participation not only is in their personal best interest but also will lead to collectively better results.
   • Identifying decision makers
     • You might need to resolve some conflict, accept (or reject) a proposed change, or approve a set of requirements for a specific release.
   • Reaching agreement on requirements
     • Customers agree that the requirements address their needs.
     • Developers agree that they understand the requirements and that t
     • Testers agree that the requirements are verifiable.
   • The requirements baseline
     • A requirements baseline is a set of requirements that has been reviewed and agreed upon and serves as the basis for further development.
   • What if you don’t reach agreement?
     • In such a situation, you’re better off moving forward—cautiously—with the assumption that you don’t have approval from the recalcitrant stakeholders
   • Agreeing on requirements on agile projects
     • Agile projects generally maintain requirements in the form of user stories in a product backlog.