requirements – Tales from the bits

3 Deadly mistakes during requirements gathering

George Bagropoulos — Mon, 21 Apr 2014 16:11:46 +0000

What are the 3 deadly mistakes that you can do during requirements gathering?
First, let me tell you a secret. There are more than 3 deadly mistakes you can do during software requirements gathering. I will focus on the deadliest 3. So let’s start! At the moment you start interviewing the client for the software she needs to build, starts the software requirement gathering process.
1. We have a tendency to assume things. My advice: Assume nothing. Especially if you have experience in the domain, it does not mean that everyone follows the same processes or uses the same vocabulary. Check all the assumptions you make with the client to create a common vocabulary and be explicit with all your communications. Add the vocabulary to all documents that you create. If you are new to requirements gathering then listen and make sure you understand everything that the client wants. Ask questions to get clarifications and take notes.
2. The client usually omits to communicate to you some very fundamental tasks that perform daily. This is not done on purpose. They have become “automatic”, part of the daily routine. Ask to observe, if possible, the working environment, the people that will use the system. Go and talk with them. Make sure that you want to make their life easier. You will find more information and you may probably discover additional pain areas or missed stakeholders. Be careful how you communicate your interest for their jobs. You are there to help everyone, you are not there to criticize or comment in a negative way. You are there to help remove the repeated mundane tasks that they perform. Tip: Map the workflow and you will discover the missing steps.
3. Accepting imprecise language from the part of the client. For example, the client says “I want a beautiful design” or “The system has to be very fast” or “The system has to have a log”. All these statements are vague. The requirements have to be precise. It is the analyst’s job to make this happen. What is the definition of beautiful? What is the definition of fast? What to log? Be as specific as possible, draw screen mockups, discuss about responsiveness of the user interface.
The above 3 mistakes left unaddressed ensure the failure of your project.

Do you have more mistakes to suggest? Please feel free to add to the list.

To Prototype or Not to Prototype?

George Bagropoulos — Tue, 22 Dec 2009 19:04:00 +0000

What is a software prototype?
A prototype usually simulates a few aspects of the functional requirements of the system under development and may be completely different from the eventual implementation.

Why do we use software prototypes?
As software engineers it is possible to use prototypes in order to be able to investigate concepts, visualize design options and help research alternative solutions for the problem on hand. A software prototype helps in many ways:

Having a prototype helps the elicitation of further system requirements. When customer stakeholders actually see a prototype, from experience, most of the times say that something is missing. This process is very helpful in validating system requirements.
User interface design is a key factor for the success of the software under developement. Presenting and collaborationg wirth end users using a UI prototype is a very nice way of producing widley accepted interfaces.
A prototype can be used in the testing process comparing it with the system to be delivered to the customer. That means, entering in both systems (prototype and application) the same data and compare the output results. If the results are identical then there is no fault detected. (Sommerville, 2006, p.409-410)

Although prototypes have great benefits for the software project, they hide some dangers. One major danger is to use a prototype and develop it further to a product. The prototype is for experiments and proof of concept. It has no “depth” or quality build in it.

Using a prototype can be viewed as a risk reduction process. This process may introduce new risks to the project if not handle carefully. Except the risk mentioned above there are also other risks involving the software prototype. The risks are:

The customer gets a wrong impression on the stage of development. Seeing a working prototype is confusing to him and thinks that the software is almost ready. It is of paramount importance not to let stakeholders to think of the prototype as an early version of the software system.
Users may confuse the hows of the user interface and not focus on what’s of the prototype. The prototype will be used to validate the requirements of the system and not how the system will look and how it will operate.
Users may believe that the prototype performance will be the end software product performance. It must made clear to customers that in the prototype are not any security features or optimized algorithms. A good habit is to use a delay timer to simulate the actual system response time.
(Wiegers, 2003)

From personal experience I know that stakeholders confuse the prototype as an early version of the system. I was building hotel management software to handle the front office jobs of a hotel. I delivered a prototype to the customer soon after we had finalized the description of the software requirements. The prototype was to test what the menu navigation would be, what critical functions (reservations) the software will perform. After the demonstration of the prototype the customer refused to believe that it will take several months of development to finish the product. It took me several meetings with the customer to convince her that it was a prototype and not an early version of the software. Sometimes managing customer expectations can be very difficult.

As a conclusion software prototyping can reduce the ambiguity of functional requirements and shorten development schedules. We must include time in the project schedules for building several prototypes and state why we want to build them. (Wiegers, 2003)

From my experience even early prototyping screen mock-up on paper can help describe the requirements of a software project.

What software can be used to create prototypes?
I have used pencil sketching for Mozilla Firefox, I know that Adobe’s Dreamweaver can be used for fast prototyping. An idea is also to use Iron Speed designer. There are many more tools listed in Cunningham & Cunningham wiki.

References

Sommerville, I (2006). Software Engineering. Addison Wesley / Pearson 8th Edition. ISBN: 0321313798

Wiegers, Karl E. (2003). Software Requirements, Second Edition. Microsoft Press. ISBN: 9780735618794

Software system requirements review

George Bagropoulos — Fri, 11 Dec 2009 13:16:00 +0000

Software system requirements are describing:

the system to be build
its functions
its purpose

Requirements are used to define these constraints and articulate beyond any misinterpretation the software system to be build.
The term “requirement” is used very broadly in software systems. It includes:

the Functional Requirements,
the non-Functional requirements
the domain requirements.

The Functional requirements state what the system should do and what the system should not do. Meaning how the system will handle input and what output to produce.
The non-Functional requirements describe attributes of the system as a whole. To give an example, a non-Functional requirement may be the response time of the system to user requests.
Domain requirements are derived from the application domain. This means that the software system might comply with some international standards.

I think that it is important to use a categorizing schema in order to be sure that all requirements are covered and to reduce the risk of not considering some important aspects of the system.
FURPS+ is used in Unified Process to categorize requirements. FURPS stands for Functional,Usability, Reliability, Performance and Supportability. The + stands for Implementation, Interface, Operations, Packaging and Legal.

It is very important to validate requirements after defining them. Correcting requirements during a requirements review has a small cost for the project. If errors to the requirements are found in later stages of software developement the cost to correct them is much bigger.

Stakeholders of the system may have different needs from the system and sometimes these needs may be conflicting. Thus, it is important to perform validity and consistency checks to the requirements. The customer and the software development team should review the requirements to ensure that the requirements correctly describe the system to be build. All the requirements of the system should be verifiable and comprehensive. It must be clearly stated who enforced a requirement in order to be able to trace back to the originator in case of a requirement change. For each requirement is good practise to state the adaptability of the requirement, meaning what the effect on the system will be if the particular requirement is changed.

After the requirements are reviewed and the proper use cases are written along with all the documentation to describe the system a requirements management system must be activated in order to:

Control changes to the requirements in a systematic way
Keep in synchronization project plan with requirements
Track the status of the requirements
Ensure that all team members have correct latest version of the requirements.

It is very important to have a conflict resolution procedure to detect and reolve conflicts. Stakeholders must have active involvement in change requirements interaction. Monitoring change and active stakeholder involvement greatly reduces system errors and increases stakeholder satisfaction and system effectiveness.

As a coclusion it is important to walkthrough the customer through the system using use cases and scenarios discussing all requirements. It is also important to insist that domain experts be present to correclty identify the requirements of the system.

References

Larman Greg(2002). Applying UML and Patterns:an introduction to object oriented analysis and design and the Unified Process. Prentice Hall 2nd ed.

Robinson,W.N, Pawlowski, S.D, and Wolkov, V(2003). Requirements interaction management. ACM comput. Surv. 35,2 pp. 132-190. DOI=http://doi.acm.org/10.1145/857076.857079

Sommerville,I (2006). Software Engineering. Addison Weasly/ Pearson 8th edition.

Wiegers, Karl E.(2003). Software Requirements, Second Edition. Microsoft Press