1. Thoughts Before Requirements Gathering

2. Requirements Gathering Functional Requirements – Functional requirements explain what has to be done by identifying the necessary task, action or activity that must be accomplished. Functional requirements analysis will be used as the toplevel functions for functional analysis. Non-functional Requirements –Non-functional requirements are requirements that specify criteria that can be used to judge the operation of a system, rather than specific behaviors. Performance Requirements –The extent to which a mission or function must be executed; generally measured in terms of quantity, quality, coverage, timeliness or readiness. During requirements analysis, performance (how well does it have to be done) requirements will be interactively developed across all identified functions based on system life cycle factors; and characterized in terms of the degree of certainty in their estimate, the degree of criticality to system success, and their relationship to other requirements.

3. Requirements Gathering Design Requirements –The “build to,” “code to,” and “buy to” requirements for products and “how to execute” requirements for processes expressed in technical data packages and technical manuals. Derived Requirements –Requirements that are implied or transformed from higher-level requirement. For example, a requirement for long range or high speed may result in a design requirement for low weight.

4. 10 Rules for Successful Requirements Gathering To be successful at requirements gathering and to give your project an increased likelihood of success follow these rules: 1.Don't assume you know what the customer wants, ask. 2.Involve the users from the start. 3.Define and agree the scope of the project. 4.Ensure requirements are specific, realistic and measurable. 5.Gain clarity if there is any doubt. 6.Create a clear, concise and thorough requirements document and share it with the customer. 7.Confirm your understanding of the requirements with the customer (play them back). 8.Avoid talking technology or solutions until the requirements are fully understood. 9.Get the requirements agreed with the stakeholders before the project starts. 10.Create a prototype if necessary to confirm or refine the customers' requirements.

5. Common Mistakes 1.Basing a solution on complex or cutting edge technology and then discovering that it cannot easily be rolled out to the 'real world'. 2.Not prioritising the User Requirements, for example 'must have', 'should have', 'could have' and 'would have,' known as the MoSCoW principle. 3.Not enough consultation with real users and practitioners. 4.Solving the 'problem' before you know what it is. 5.Lacking a clear understanding and making assumptions rather than asking. M - MUST: Describes a requirement that must be satisfied in the final solution for the solution to be considered a success. S - SHOULD: Represents a high-priority item that should be included in the solution if it is possible. This is often a critical requirement but one which can be satisfied in other ways if strictly necessary. C - COULD: Describes a requirement which is considered desirable but not necessary. This will be included if time and resources permit. W - WON'T: Represents a requirement that stakeholders have agreed will not be implemented in a given release, but may be considered for the future.

6. Organizational Culture “Organizational culture” refers to a system of shared values, understandings and perspectives which are held in common by the organization’s members and which distinguishes it from other organizations. It is comprised of the patterns of collective behavior which determine which things get done, how they get done, and by whom

7. Organizational Culture Generally, seven primary characteristics combine to form an organization’s culture. Each falls at a certain point on a spectrum between two extremes. 1. Commitment to innovation/creativity: Are people encouraged to take risks or to proceed with caution? 2. Attention to detail: Are people expected to demonstrate precision in their approach to tasks or is there freedom as to how work may be done? 3. Outcome orientation: Are results more important or the process by which they are achieved? 4. People orientation: Is the program ultimately more important or are people? 5. Team orientation: Are activities organized more around individual contributions or team efforts? 6. Commitment to cooperation: Are people expected to be aggressive and competitive or amiable and cooperative? 7. Stability: Are activities aimed at maintaining the status quo or growing and progressing?

8. In a nonprofit organization, the mission not the profit is the driving force behind the organization. nonprofits are typically resource constrained. This phenomenon can have an impact on management’s ability to implement change as well as increase compensation. the nonprofit sector tends to be process oriented and consensus driven, both of which can slow decision making. In the corporate world, the pyramid-like organization can quicken decision making and implementation.

9. The nonprofit sector also can differ from the corporate world in the type of employee. This sector tends to attract bright individuals who are passionate and committed to their cause. They are working for their nonprofit organization because they believe they are making a difference in the world, or because they believe in the direction of their organization, or that they have a lifelong passion for the work that their group does.