Requirements analysis

Thousands of activist projects are doomed from the start because they are based on a faulty understanding of the constituency's position regarding the social or economic problem that must be solved.

In many cases, the consituency's position is inchoate and many commonly held positions are self contradictory or are fundamentally incompatible with views held by members operating at a [different Zachman layer] within the constituency.

Requirements analysis promotes cross layer communication and aids in the process of finding common ground on the problem definition stage of what the group's "Ask" shall be.

Introduction
Requirements analysis originated in software development process theory during the eighties in order to address profound failures of communication regarding extremely expensive and strategic custom business software that non IT companies needed for competitive advantage in their markets. Concepts of the process have been applied to Public Policy system development [USA] [Greece], but it is still widely unknown outside the custom business software field. The hypothesis is that for issues analysis, the same methodology can be applied, using decomposition of functional requiremenst with full recognition of the layers of stakeholders.

Requirement definition
One simple way of identifying them:  A requirement will answer the question,
 * 1)  a condition or capability needed by a political constuency to achieve a policy objective.
 * 2)  a condition or capability that must be met or possessed by a policy proposal to satisfy a coalition contract, the Party charter, law, or other formally imposed document


 * What will the policy change that is required in order to deliver the political objective?


 * --And not--


 * “How will it change”

View model
Requirements analysis is within the domain of a field of design methodology called Enterprise architecture (EA). In political party language, the Party is the Enterprise, and the party structure (Policy petal, Executive petal, Caucus petal) represents its architecture. The  Zachman oriented model typically presents these elements as "layers", a metaphor that can be misleading becuase it suggests hierarchy. The conceptual framework applies to all organisation types whether they are hierarchically structured or not. For the purposes of this wiki, in the requirements analysis "layers" correspond to Views.

The parable of the Elephant with blindfolded individuals reporting their perceptions provides an intuitive entry point to the multi layer ["view"] model of design analysis. The Zachaman and other EA models are detailed decompositions that provide a methodology for identification of the concerns within each of the layers. For illustration of the detail involved, consider the following chart corresponding to decomposition of a solution from the perspective of a single layer:



Note that this same matrix is repeated for each Layer, producing a 3 dimensional organizational view of Green Party Positions.

Note also that the term "Technology" is an abstract reference to a Policy technology:  For example- taxation of social bads is one such "theory specific"  policy technology. One solution corresponding to this policy tool would be a Carbon Tax.

What is a good requirements statement?
From a Business Analyst blog:  Inserted comments are in square brackets[].

Ideally, every requirement statement (written from the user's perspective) should contain:

[There is little organizational capacity for the requirement to be actioned without a constituency advocating for the requirement, that the consitutency is motivated to achieve the benefit it delivers, and a concrete measurement that the constituency can point to in order to claim that the requirement is or is not being delivered on.]
 * A user role that benefits from the requirement
 * A desirable state that the user role wants to achieve
 * A metric that allows the requirement to be tested, where applicable

In addition to the challenge of ensuring that each requirement statement abides by the above structure, here are some useful tips on what to do and what not to do which should be taken into consideration.

15 Tips for Writing a Good Requirement

 * 1) Define one requirement at a time - each requirement should be atomic. Don’t be tempted to use conjunctions like and, or, also, with and the like. This is particularly important because words like these can cause developers and testers to miss out on requirements. One way to achieve this is by splitting complex requirements till each one can be considered a discrete test case.
 * 2) Avoid using let-out clauses like but, except and if necessary.
 * 3) Each requirement must form a complete sentence with no buzzwords or acronyms.
 * 4) Each requirement must contain a subject (user/system) and a predicate (intended result, action or condition).  Questions Who? and What?]
 * 5) Avoid describing how the system will do something. Only discuss what the system will do. Refrain from system design. Normally, if you catch yourself mentioning field names, programming language and software objects in the Requirements Specification Document, you’re in the wrong zone. [Answers to how Questions are allowed, but not if they regard how the solution works.  How questions should apply to problems in the current process.  How does the current system work that is undesirable?]
 * 6) Avoid ambiguity caused by the use of acronyms like etc, approx. and the like.
 * 7) Avoid the use of indefinable terms like user-friendly, versatile, robust, approximately, minimal impact, etc. Such terms often mean different things to different people, making it difficult to define their test cases.
 * 8) Avoid rambling, using unnecessarily long sentences or making references to unreachable documents.
 * 9) Do not speculate; avoid drawing up wish lists of features that are impossible to achieve. Saying you want a system to handle all unexpected failures is wishful thinking since no system will ever be a 100% what you want it to be.
 * 10) Avoid duplication and contradictory statements.
 * 11) Do not express suggestions or possibilities. You can identify these wherever you see statements with might, may, could, ought, etc.
 * 12) Avoid creating a jigsaw puzzle where requirements are distributed across documents, causing you to cross-reference documents. This can make your RSD extremely difficult to read.
 * 13) Do not refer to a requirement that is yet to be defined. Again, your objective is to make the document as much of an easy read as you can.
 * 14) Use positive statements such as “The system shall…”, instead of “The system shall not…”
 * 15) “Shall“ should be used where requirements are being stated, “Will” should be used to represent statements of facts; & “Should” to represent a goal to be achieved.

Simple questions
Use a pragmatic definition that will help you as you try to identify requirements in your project.

Example guidance statement to stakeholders: Requirements are precise statements that answer a particular question and do no more than that.

Phrasing as "The solution will..."
Examples:
 * The solution will enable users to record customers sales
 * The solution will enable Customer Order Fulfilment letters to be automatically sent to the warehouse.
 * The solution will enable government to create new money for funding neeeds.

Card sorting
How people arrange entities can reveal their requirements. More here