What Customers Want? Introduction to Software Requirements -PART 1

We are living an era where services industry is booming. Current markets are full of new faces other than conventional manufacturing and tangible products. Information technology service is one of those rising industries in services sector. IT Professional and consultancy services are on top of this sector. A major shift in thinking between product-based and service-based industry is the personalization thinking and focused targeting (excluding public services). Unlike mass targeting of conventional products, IT services are mostly targeting individual customers. The time of having one product or service fits all is over!

One of the most important aspects to achieve focused targeting, is a proper understanding of customer needs and requirements. In this post and a following series, I will tackle the subject of software requirements. Gathering, understanding, analyzing, communicating, and building customer requirements is an old and a new subject at the same time. In this series of posts, I will try to explore the virtues of software requirements engineering, required skills, schools of thoughts, and techniques.

Requirements engineering is a core skill for any IT consultant or IT worker in any level. It differs only on the level of mastering it. But I believe all of IT industry workers need to have a minimum knowledge about requirements engineering since it answers a bigger question of what customers want?

Studies show that 80 to 85% of project failures are due to either missed or incorrect requirements. I remember from old days a very expressive conversation I read in the classic novel “Alice in Wonderland” when Alice asked a cat:

Would you tell me please, which way I ought to go from here? 
That depends a good deal on where you want to get to, said the cat. 
I don’t much care where -, said Alice. 
Then it doesn’t matter which way you go, said the cat. 
Lewis Carroll, 

There still many IT professionals and enterprises dealing with software requirements with the mentality of 70s, 80s, and 90s. However, we will not appreciate the need for new way of thinking unless we know the history. So I will provide some background about requirements engineering history and its link to software development processes.

Back to Old Days – The Popular Waterfall Model

This model appeared in early days of software inception. It was dominating starting from 1970s onward. It is still popular till now for its intuitive linear logic. Requirements are performed at early stage and (hopefully) frozen. Requirements here are done once upfront. Below diagram depicts the waterfall model with its famous sequential stages.

 The major problem with waterfall model is the continuous changes of requirements especially in current markets. The intensive competition along with shortened products life-cycle out more pressure on adopting requirements to cope with environment conditions.

However, it is still alive for several reasons I am encountering. It is intuitiveness and simplicity. Most of companies and enterprises built their governance around this linear model. Most of companies are still building simple business cases based on this linear model. Even market is still using conventional fixed price contracts which mandates specific frozen scope! You can also add to the above reasons, the availability of skills who are knowledgeable with other paradigms and methodologies.

Iterative and Incremental Models

During 80s and 90s, remedies for waterfall limitations were surfacing. An iterative versions of waterfall were devised. Spiral, Rapid Application Development (RAD) and Rational Unified Process (RUP) are all iterative and incremental models that were out in practice. Those models achieved success in the industry by introducing project phases and multi-drops. This shortens time-to-market cycles. Requirements are collected several time during the whole engagement life-cycle. Use cases started to appear in these models. Use cases provides a good vision around the scope to be implemented.

However, these models need stronger configuration version control due to frequent changes and releases. There is additional project management overhead. Architecture should be well-monitored towards the target architecture.

Adaptive (Agile) Processes

They started in late 90s and current decade. A lot of models and variations appeared under this processes. All aim to provide lightweight documentation and more adaptive systems to changing environments.

Examples for those methods are Feature-Driven Development (FDD), Adaptive Software Development, Scrum, Extreme Programming (XP), Open Unified Process (Open IP), Lean, Crystal Methods, and others. Most (~75%) of agile implementation (worldwide) uses scrum as a method to implement agile methodology.

Requirements management under agile methodology is different. Instead of investing months in building comprehensive detailed requirements, teams focus on delivering value-added user-stories. Early delivery helps to test assumptions, architecture, and minimize project risk.

If we look at return on investment (ROI) difference between agile and other methods we can see much faster ROI in agile methods.

I will stop here in this post. In next posts, I will focus more on requirements management practices, techniques, and business analyst required qualities.