Software Best Practices

This is to pick up the thread started over here http://forums.construx.com/forums/t/14.aspx

I maintain that there are requirements about functions and characteristics (quality attributes) that define the function. As a group (function + characteristics/attributes) they make up ONE requirement.

I am focused here on Product requirements, not Project.

Earl, how do you define the term "function"?

Hi pisber,

My working definition I offer in my seminar is: 

What the product must do: actions to take, information/data to remember, business rules and policies to enforce

Hi Earl, you might think that this question is silly.

I'm programming for almost three years as a professional, so I'm just starting, but sometimes I think that

I lack a lot of documentation to get my job done well.

I've been implementing a lot of user interfaces, using the .net Framework, my question, is a performance requirement

that a customer might have, is a functional or a non - functional requirement ?

Regarding the User Interface, to start implementing, if I have the analysis phase closed, Ok it's never closed, but lets

just think for a minute that is closed. What should I expect as a implementer ? A draft of the user interface manual ?

Some requirements document with the functional requirements of the "forms" that I have to implement ?

Ok, this one might be expecting too much, requirements that are more technical and more usefull to those that are

implementing the system ?

Thanks in advance for your answer.

Regards

 

Luis 

Hi Luis,

I don't think the question is silly at all. I should write a blog posting on it. However he is the gist of a response.

You do lack a lot of documentation. I would hazard to guess that you lack most, if not all, the requirements. That is because I almost never see any group get at the requirements.

So, to start with, the UI only exists as a way to allow some user to achieve some goal. If I could have direct mind transfer to the machine, that would be better, no? So, if you grant me that, then the UI itself is a solution trying to solve some problem, namely, the user trying to achieve some goal.

OK, great, so what is that goal? Let's say it is ship a purchased product to themselves.

So, the requirement package (function + characteristics) might look something like this:
ShipProduct: gist to transport the product from the store to the customer's location
    EasyToUse: gist must feel easy to select the ship options (in this example, ease of use is a key characteristic)
        measure: 95% of all users must rate the process a 4 or better on our standard 5 point scale
        measure: Less than 1% of all attempted ship process will encounter an error
    Performance: gist must not take a long time to ship (another key characteristic in this example)
        measure: 80% of all ship requests will take less than 2 minutes form first click to final submittal
        measure: 90% of all in stock item must leave the warehouse with 30 minutes

Performance, therefore, becomes a characteristic (a non-functional) for the function. Some characteristics can be applied at the system level, that is the first level decompositions of functions must all meet the same characteristic. While often expressed this way, I find it is seldom true. Usually the characteristic is for a few key functions.

As a developer there is a difference on what you can expect and what you need to succeed. You will get all sorts of stuff, basically what the requirements developer (analyst in you case) knows how to create. Most folks know what they run into every day (screens, buttons, etc.) and so that is what you will get. What you need is to understand the goal of the customer and the key characteristics that will help them decide if the function is acceptable.

 Hi Earls,

 

thank you for your answer.

I do lack a lot of documentation, that is true, and on this particular project I had to produce another  analysis doc in order

to be able to understant how the things are done! But that's not the point here, you mentioned something that made me think.

" That is because I almost never see any group get at the requirements.  "

What do you want to say with this ? Something like, that very few groups use requirements documents, and have that kind

of practice in their organizations ? 

I start reading a book written by Ian Sommerville, about requirements, and in the introduction he says that a lot of problems

with software development, namely late delivery and software that not solves the users problems are directly releatead to

the lack of a requirements engineering process on the organization.

How could we overcome this on the software development process ? Use some had - oc process that solves our problem and continue without a way to handle properly the requirements ?

 

Best regards

 

Luis 

You will likely get a document. It will be full of statements like, "The system shall minimize noise levels." It may even have things like, "The system will display the states in alphabetical order." Both are requirements. And, if you implement them, you can hope they solve whatever concerns the customer since you can only guess. (Are they doing sound recording? Is it in a public space? Do they need to quickly find a state?)

As for how to approach it, there are many different ways. I like to think I give many practical ways when I teach our requirements seminar. The most recent approach practiced by some agile folks is to forget about trying to "elicit" them ahead of development but to have the customer there with you to explain why they want what they want while you code.

Earl, thank you for your feedback. I appreciate that you can find time to respond to many posters.

If there is a world of difference between Product requirements and Project requirements, then I know why so many projects fail! :)

Speaking seriously though, there is a slight misunderstanding and I think it is my fault for not making it clear.

From my previous post:
> Suppose we have a project whose sole purpose is to identify feasibility of a more complex
> state-of-the-art system (possibly including hardware). Where does this requirement (identify
> feasibility) belong?"

Although it is phrased in terms of a project, I was talking about product feasibility. And a "product feasibility requirement" is a product requirement. Here is why. Consider two projects with goals:

A) Test if it is feasible to develop services X,Y,Z on a server that can maintain 10,000 simultaneous connections with users from all over the world,
so that service delays do not exceed 3 seconds.

B) Develop a software system that delivers services X,Y,Z on a server that can maintain 10,000 simultaneous connections with users from all over the world, so that service delays do not exceed 3 seconds.

My claim is that the two products, the tangible results of the two projects, are different. Therefore, if you drop the feasibility requirement from product specification, you will end up developing a wrong product.

Let look at the target product requirements for projects A and B. (Hand-waving description)

Project A:
1) defect count does not matter, development speed is highest priority
2) should include (for example) 6 test servers that mimic user behavior,
3) the test servers are to be deployed on 6 different continents and include service delay measurement units,
4) high probability that it involves state-of-the-art components/algorithms/etc.
5) user interface is not needed,
6) 10,000 simultaneous connections,
7) service delay < 3 sec,
8) etc

Project B:
1) one server system (not 6) that ensures 99.9% uptime
2) low defect count,
3) friendly user interface, no hassle payment system,
4) 10,000 simultaneous connections,
5) service delay < 3 sec,
6) etc.

I see a huge difference in product requirements while the only difference in project description is the feasibility requirement: 1 vs. 2 systems (system + test modules), low vs. high defect counts, user-friendly vs. no user interface, etc. Apparently, feasibility is tightly coupled with other product requirements, at least it is in the same world. ;) Thus, I conclude that feasibility requirement is a product requirement. Do you think it makes sense?

 

Nick, No problem, requirements are some of my favorite things. I actually fully agree with what you wrote. The "fuction" part of the requirement determines scope. That is, it calls out which characteristics are in play or not. The characteristices, more precisely - the targeted values of the characteristics, determine cost and duration. In your example, you used the same function and different points on the same set of characteristics. Given my defintion above that one has more aggressive targeted values of the characteristics is going to demand a completly different design than one with looser values. (Don't tell anyone that I suggested "loose values"). So my first "feasibility" project also has project requirements of "minimal cost and speed of execution. The design (technical prototype, spike) will be different than the second project becuase I am asked to solve a different problem. Feasibility, as I think I understand what you are writing, suggested a different problem to solve. This will give us different target values for the same characteristics, which will greatly impact cost and duration.

I think the requirements usually need some work to develop from the fluffy, furry kind that are needed for contracts, and the technically precise, testable requirements needed for development. It is unusual for customers to be able to provide the latter so it is a matter of analysis and judgement to get from one to the other. Certainly the fluffy ones will have statements like "performs better than" and "is easier" and suchlike but the requirements that are needed for development need specific testable statements, for example, "performs 1500 updates in under 1 second".

For that reason, we've maintained two sets of coupled requirements. The fluffy ones which are the results of negotiation with the customers, are used to inform the technical requirements. Where there is clarification required, the customer is consulted by negotiators who can interpret the technical questions in context and get the necessary answers. Mostly it works well and the customer is then not trying to specify details they are technically unable to address, and the customer gets consulted on anything that enables us to meet their requirements.

Some contracts have highly competent technical representatives on the customer side in which case they may cut straight to the chase, but more often some mechanism is often needed to do the technical mediation.

It gets more interesting when we negotiate user acceptance tests because we similarly have a much more detailed technical spec which is a superset of those required to meet the customer tests.

By maintaining good change control, the drift in requirements is assessed continuously and where needed, the customer rep is involved in assessing the implications. It's a difficult area because we'd like static requirements but the world doesn't so we accept that establishing requirements is not just about analysis. We rely heavily on use cases as well.