Learn Software Development » Requirements

What is the difference between functional and non functional requirements?

ashish — Sun, 26 Feb 2012 19:44:44 +0000

People often interchange the characteristics of functional and non functional requirements while discussing them, including experienced people who should know better. This concept was given official acceptance in the year of 1982. In this post we have tried to list out all the basic differences between the functional and non functional requirements that will help you understand the two types of requirements. So here we go:
1. Functional requirements are those requirements of a software system or application that are used to define the features and functionalities of the system or its constituent components. On the other hand non functional requirements are those requirements that focus on the quality of the software system or application. There are other names for non functional requirements like constraints, quality attributes and goals etc. Non functional requirements basically denote the quality of the non behavioural requirements of a system.
2. As a typical function is a set of input, processing and output, the typical functional requirements can be data manipulation, calculations, processing and other technical details. A functional requirement can define a specific functionality which tells us that what a system is expected to achieve. The non functional requirements provide a helping hand or support these functional requirements. The non functional requirements support the functional requirements by defining additional constraints for them like security, reliability and other performance related constraints.
3. Functional requirements are all about the behaviour of the software system or application and are stored in use cases whereas the non functional requirements are concerned with the non behavioural aspects of the system.
4. The way of expressing functional requirements is somewhat like “system ought to do ”. On the other the non functional requirements are expressed as “system expected to be ”.
5. Functional requirements are all about the system design i.e., the implementation design and plan for the functional requirements whereas the non functional requirements are all about the system architecture i.e., implementation strategy for the non functional requirements of the system.
6. There is another purpose of the functional requirements which is that they specify the results for the software system or application in the same manner as the non functional requirements specify the characteristics of the system like accuracy, reliability and cost etc on a whole basis.
7. Functional requirements are employed to drive the architecture of the application of a system with simultaneously having the non functional requirements driving its technical architecture.
8. During the requirement analysis of the functional requirements, use cases are generated after the validation of the functional requirements.
The non functional requirements are of two types as described below:
(a) Evolution qualities: These are non functional requirements like maintainability, testability, scalability and extensibility which form an integral part of the software architecture.
(b) Execution qualities: These are non functional requirements like usability and security. These qualities can be observed during run time.
9. A typical functional requirement has a unique number and name and contains a brief summary of itself and of course a rationale. All these aspects help the programmers to understand the usability of a requirement. It mainly defines the behaviour of the software system. Non functional requirements when compared to functional requirements are used for specifying the criterion that helps one in deciding about the system rather than justifying the behaviour. Some examples are back up, documentation, accessibility, extensibility etc.

Agile Software Requirements	More About Software Requirements	Software Requirements 2

Scrum – Provides you a good quick feedback on accuracy of estimates for tasks ..

ashish — Sat, 10 Dec 2011 21:24:28 +0000

One of the major dependencies for a successful project schedule is in terms of the accuracy of estimates versus the reality. In short, you want to measure the difference between the time estimate for a project (or a task inside the project), and the actual effort needed. For such a measurement, you would want to ensure that variables such as changes in feature specs or design between the estimate and the actual execution are eliminated; if your design changes between the initial estimate and when you sat down to do it, then it is very difficult to make such a measurement, or to learn something from such a measurement.
Consider the following example; a colleague of mine used to review the actual time spent on a task, and then compare it with the estimate for the same. He used to do this for multiple tasks, and where the variables (such as requirement changes, or design changes, etc) did not change too much during the time period, he would slowly start to learn which person tended to do the task earlier than the estimates given by the same person, and also the reverse. The next time he would ask these people for an estimate, he would accordingly make the relevant changes in the estimate he got, and then use the modified estimate for the final planning.
Scrum makes this review even more easier. In Scrum task tracking, the team is supposed to provide an update every day on what has been done, and which tasks will take up more time than initially planned. As a result, and especially because tasks tend to be defined in terms of hours and a few days rather than 5+ days, it becomes immediately clear as to which tasks are getting delayed. So, when you are using Scrum in your team, you will immediately start to see the variance between estimates and actual figures. Now, the development team may think that you are trying to find fault, but getting the estimates to be as close to actual figures is very important. This helps you better estimate the deliveries at the end of the Sprint, and prep the customer / product owner about what all is going to be delivered for which you want feedback. This also helps stakeholders get more confidence in the work done by the team.
Being able to see variance could also help you to figure out more research into why the estimates are getting varied; is it because the details provided by the Product Owner are not detailed enough to generate the right estimates, or is it because there are some design issues that cause more effort than people estimate. Make sure that this investigation is done.

The Elements of Scrum

The One-Page Project Manager: Communicate and Manage Any Project With a Single Sheet of Paper

Practical Software Metrics for Project Management and Process Improvement

What is a MVP in terms of software product development ?

ashish — Wed, 07 Dec 2011 19:54:18 +0000

A lot of have people have not heard of the term called MVP. The full form of MVP is called Minimum Viable Product, and represents the set of features that is believed to be essential for the release of a product. The use of MVP is a strategy that decides the number of features that should be built into the product, just those set of features and no more. I will describe with an example as to how the MVP was used to drive the discussions about the list of features that should be part of the product version, given the compromises that need to be made with regard to the availability of resources, the time available, and the need to have features for the release.
Consider a case where a new version of the product needs to be released, and there is the familiar discussion about the feature list that needs to be approved for the product version. The product management team could come up with a large number of features, but that is just the starting point. The features need to be arranged in a prioritized set of features, associating them in terms of the most important, the ones that are somewhat less critical, and the ones that are good to have. This activity can take a fair amount of time, since the product management team has to balance the need for a feature in terms of meeting competitive pressures, in terms of getting good reviews (the initial set of reviews generated by professional reviewers in tech blogs and magazines), and being useful to customers, since that generates the overall positive buzz among customers in various tech / software related forums.
Once this priority has been set for the features, these features, especially the most important features, need to be set in terms of the MVP for the release. Getting such a list of features without which the product will not ship helps guide the discussion beyond this point. Thus, once the Product Management has set out a list of features that need to be done for the product to ship, and have convinced the stakeholders including management and the engineering team about this, then the rest of the discussion is about how to meet the MVP.
If the timeframe or the number of resources are not enough to get the feature set as defined in the MVP done, then the discussion moves towards debating the timeframe, as well as the number of resources available to the engineering team. In our current case, the number of features in the MVP were not being met, and the release was critical, hence the team got authorization for an increase in the number of engineers so that the feature set could be met. This was not possible until the must have feature set was defined, these forming the MVP.

Problem – When stakeholders disrupt the prioritized feature list of items for a Scrum team

ashish — Wed, 09 Nov 2011 19:14:50 +0000

When you start working out some of the basic assumptions of how a Scrum team is supposed to work, one of the base assumptions is that the Product Owner sets the priorities of all the features / User Stories for a Sprint. Now, depending upon business needs, this order can even be changed midway during the Sprint (should be avoided in most cases is what most of the literature says) if there are pressing needs to change the priorities. This can also be done by ending the current Sprint at the point where the decision to change the Sprint Backlog is made, and starting a new Sprint (which can be set to end at the same time as the previous length of the Sprint).
However, this becomes a problem in the case of service teams. Consider a team that prepares some kind of infrastructural work for other teams; in this case, the User Stories are derived from the needs of other teams, but controlled by a Product Manager who decides the priority for the requests coming in from other teams. This can be quite problematic, since other teams all have their own priorities, and the Product Owner can have a difficult time just trying to balance the requirements of the other teams. If the team is lucky, the requirements of the other teams can be somewhat similar, which makes the work of the Product Owner easier.
I have also see a case where the Product Owner had a really tough time, having to fend off a number of pushes from the different stakeholders that impact the work. So, the Product Owner decides the User Stories based on some inputs, and sets the Sprint Backlog for the defined interval. The team starts work.
And then the pressure starts. Another team suddenly finds that their external environment has changed, and decide that they need something fairly quickly from the infrastructure team. The team finds that the external stakeholders are applying additional pressure and the pressure in this case can rise to such an extent that the team is forced to change their User Stories midway during the Sprint. Once in a while, a team can endure this and understand this, but if this pressure and change in Sprint features keeps on happening, the team starts questioning their implementation of Scrum and will suffer reduced morale. However, it is not realistic to assume that the Product Owner can easily overcome the external stakeholder pressure.
I do not have a good solution to this one, and did not have one when the ScrumMaster of the team asked for opinions.

How to define tasks for a User Story without spending a fair amount of time on these ?

ashish — Sun, 30 Oct 2011 18:56:46 +0000

We seem to find ourselves running into a fundamental problem during out Sprint planning meetings. Some of it is from our older methods, but partially it also seems to be a problem with the way we are using our Scrum processes. Consider the process before getting into Scrum. We would have a list of features defined and agreed upon by the Engineering and Product Management teams to be done in the defined product development time cycle. However, things were problematic when actually getting into the actual stage of working out the tasks for these features. Many of these features involved features that were not done before, and so it was required that these features be broken down into tasks, and the team leads were assigned to this purpose. It would take a matter of some time for the features to be actually broken down into a matter of tasks. The feature team would need to have a few meetings to discuss the feature, talk to the User Design specialist to understand the way that the feature would work, and then work out the tasks.
However, it would take more time to work out the estimates for the task, and in many cases, this was a matter of guesswork, since the work required for the tasks had never been done before; getting these estimates involved some amount of discussion. And once these estimates were in place, when the actual work was happening, these estimates did change many times (sometimes the User Design was different from the one initially considered, and in many cases, the estimates were actually different from the work that was needed to be done to complete the task). This meant that the total effort needed to complete a feature was different from the estimates; and this happened for many of the features.
Now, when we started using the Scrum process, this became an open question. For many of the major User Stories that were a translation of the major features, getting tasks broken down into the User Stories was a major effort by itself, and it was postulated by the team that earlier it would take so much time to break down the features into tasks, how would it be possible to do this during the Sprint Planning process ? It was somewhat difficult to answer this question, although we did some amount of planning on how to define User Stories in such a manner that they would be readily understandable and could be broken down into discrete tasks that could be estimated with some amount of accuracy. This took some time to actually happen, and there were many cases where the effort estimation did not match the actual effort needed for the tasks.