REQUIREMENTS

SW - REQUIREMENTS Ambiguity
SW - REQUIREMENTS Ambiguity
REQUIREMENTS: Understanding the needs of the customer and make it clear specifications and system requirements, is the crucial first step.
IMPORTANT :: To be able to make more realistic estimate of the expected workload and start planning, we should have answers to these two CRUCIAL questions upfront:
1. What assumptions and contractual preconditions have not been yet fulfilled -- so we can NOT start to make any estimate of the volume of work and start to plan the development?

2. Have the end user/ client CONFIRMED the future solution mockup (interface layout, desired software walk-through, operating procedures document or prototype, requirements checklist ), before the coding has started!?

The first step toward developing accurate and complete specifications is to establish correct requirements.Establishing correct requirements is extremely difficult task and is more of an art than a science.
---------------------------------------------------------------------------------------------
DESIGN / SPECIFICATION: Definition of necessary (time, cost and working methods), human and technological resources for the realization of future system is next step.
FEATURES: Customers sometimes have only a vague idea of what may be required for certain features to cost. For this once communicated clearly the costs, you can readjust the features specification, and get a second, more contained, project definition with the budget acceptable to the customer.
-------------------------------------------
Why Have Official Requirements?
------------------------------------------
An explicit set of written requirements, specifications and design guidelines is important for several reasons.
Explicit requirements help to ensure that the user/customer rather than the programmer drives the system's functionality. If the requirements are explicit, the user can review them and agree to them.
Explicit requirements also help to avoid arguments. If you have a disagreement with another programmer, designer or customer, about what the web system, program or applications is supposed to do, you can resolve it by looking at the written requirements, specifications and design guidelines.

------------
PLANNING
------------
* Make sure to plan before starting the development or implementation.
Without adequate planning, it is difficult to really understand what it will take to complete a project successfully. Lack of planning leads to inadequate preparation, unexpected problems, and poor execution of milestone tasks.
Poor planning is a worst practice because:
If you don't have written plans, you are using your memory to keep track of things, what is unreliable and dangerous. Planning is an excellent tool for getting things out in the open. Good planning forces you to think about your projects before you set about doing it and to put your thoughts down on "paper". This alone can help you prevent many project failures and delays.
Without plans, it is difficult, sometimes even impossible to get a clear picture of all the things that you are working on and what still needs to be done.

-----------------------------
DATA AT THE BEGINNING
-----------------------------
At the beginning I am focused on data repositories, all files in the system, and their data records structure. And what must be done in order to process input files into desired output behaviour and data. What are the test scenarios, and if the customer has provided test data together with requirements?
It is important that the customer provides or at least validates "test data sets, input files and desired output " together with "desired feature requirements".

...................................................................................................................
Posted by marty cagan on October 14, 2010
I’m not the first person to come to this conclusion, but over the years, I’ve really come to dislike the entire concept of a “requirement.”
I’ve learned that so many things that look like “requirements” really are just a perception, or assumption, or an illusion.
Customers especially think they have “requirements” but really they’re just a hypothesis on what might solve some probably unstated problem.
Stakeholders have “requirements” that are really just their personal theories or assumptions on what might solve again a probably unstated problem.
On the other hand, I’ve learned that the true requirements are often not at all obvious at the start, and mostly emerge later when observing and interacting with real users.
I’ve also learned that the design directions you take will often lead to very different functional requirements. It really is true that form and function are completely intertwined. The old Waterfall theory of software had it essentially backwards.
It’s also rarely black and white, where a requirement is either totally absolutely essential, or not. Very often you can build up the value in one area to compensate for other areas. Or, if something isn’t feasible technically, we can come up with other approaches that suffice, or even work better.
I find defining and designing product is more like cooking in this respect in that if an ingredient is unavailable, you can often get creative and substitute something else or a combination of things that aren’t quite the same but may be even better. It’s the result that matters, not our pre-conceptions.
I much prefer Agile methods like Scrum over Waterfall because of how much less weight is given to “requirements” in Scrum. However, even if expressed in a user story, there are still dangers with Product Owners and their teams thinking something is more of a “requirement” than it really is.
Our only real requirement is to discover product solutions that work well for our users, our customers and our business.

------------------------------------------------
Early prototype risky and unfamiliar parts
------------------------------------------------
Have you prototyped risky or unfamiliar parts of the system, creating the absolute minimum amount of throwaway code needed to answer specific questions?
Divide and Conquer
As Edsger Dijkstra pointed out, no one's skull is big enough to contain all the details of a complex program, and that applies just as well to design. Divide the program into different areas of concern, and then tackle each of those areas individually. If you run into a dead end in one of the areas, iterate!
Incremental refinement is a powerful tool for managing complexity. As Polya recommended in mathematical problem solving, understand the problem, devise a plan, carry out the plan, and then look back to see how you did (Polya 1957).
Design is an iterative process. You don't usually go from point A only to point B; you go from point A to point B and back to point A.
Virtually all systems undergo some degree of design changes during their initial development, and then they typically change to a greater extent as they're extended into later versions. The degree to which change is beneficial or acceptable depends on the nature of the software being built.

---------------------------------------
Establishing Correct Requirements
---------------------------------------
The first step toward developing accurate and complete specifications is to establish correct requirements. As easy as this sounds, establishing correct requirements is extremely difficult and is more of an art than a science. There are different steps one can take toward establishing correct requirements. Although some of the suggestions sound fairly obvious, actually putting them into practice may not be as easy as it sounds. The first step is to negotiate a common concept with the customer/stakeholder.
There is a quote by John von Neumann that states "There's no sense being exact about something if you don't even know what you're talking about."
Communication between the business analysts, system designer/architect and customer is vital. There is no point in trying to establish exact specifications if the business analysts and customers cannot even agree on what the requirements are.
Problem stems from ambiguities in stating requirements. Ambiguous requirements can be caused by missing requirements, ambiguous words, or introduced elements. There are also missing requirements. "a group of people" in the above requirement is an example of ambiguous words. What exactly does "group" imply? A group can consist of 5 people, 100 people, 1000 people, etc.
It is important to eliminate or at least reduce ambiguities as early as possible because the cost of them increases as we progress in the development life cycle.

----------------------
Acceptance testing
----------------------
Acceptance testing is a testing with respect to user needs, requirements, and business processes conducted to determine whether or not a system satisfies the acceptance criteria of a given use case. It is usually performed by the expert-user, customer or other authorized entity to determine whether or not the system is acceptable. A test pilot is an aviator who tests new aircraft by fling specific maneuvers. In aeronautics top pilots, navigators and engineers conduct flight tests and at the end of the test missions they will provide evaluation and certification data.


----------------------------------------------------------------
Handling Requirements Changes During Construction
----------------------------------------------------------------

Use the requirements checklist before signing the development contract. If your requirements aren't clear enough, stop work, and make them right before you proceed.

Make sure everyone knows the cost of requirements changes. Clients get excited when they think of a new feature. The easiest way to handle such feature-intoxicated people is to say, "It sounds like a great idea. Since it's not in the requirements document, I'll work up a revised SCHEDULE and COST estimate so that you can decide whether you want to do it now or later." The words "schedule" and "cost" are more sobering than coffee and a cold shower, and many "must haves" will quickly turn into "NICE to haves."