Functional vs Performance Requirements

"Performance Requirements are about criteria and meeting criteria, Functional Requirements are about describing how a system behaves."

I think I agree with  that statement.

So for example, a Performance Requirement could be:

The laptop shall withstand shock of 20g's (good laptop!).

The criteria we are talking about is shock. To verify this requirement, we would measure the end product against this criteria, and see if it meets it.

A functional requirement:

The add button shall sum the values in fields A and B and present the result in field C.

We are describing how the end product will function, or (in other words), we are describing the end product's behavior. To verify this requirement, we would exercise this functionality and observe the results.

A Use-Case is not a Requirement

A small conversation from a past interview has popped back in my mind. The interviewer told me how important use-cases are when going from high-level requirements to the actual software that you write. I completely agree with this, and to this day I am kicking myself for not saying this first. I have a feeling the person interviewing me was seeing whether or not he could lead me to discuss the importance of use-cases and my experience developing them, but for some reason it didn't quite come to me.

Anyhow, amongst discussing use-cases, I asked him whether or not a use-case is a requirement. I recall (although my memory is a bit fuzzy) that he said it wasn't a high-level requirement, but a derived, lower-level requirement, or specification that gets into implementation. I nodded, but realized that I didn't necessarily agree with this (again I am kicking myself for not stating this out-right).

Requirements
A requirement is a nugget of information that describes a characteristic that a system must fullfill. A derived requirement, or specification, breaks down these morsels of information further, and typically has a "consists of" or "satisfies" parent-child relationship[1].

Requirements can be indexed, reused, and (importantly) associated with other requirements. The end result, a database of associated requirements, can be divided up and used to generate all sorts of things, including the end-deliverable, project plans, and work break down structures. That is why good requirements and specifications, along with whatever tool presents and manages them, are so powerful. They drive not just the deliverable, but the entire project.

Use-Cases
A use-case is not a requirement. A use-case is a sequence that involves an actor, start conditions, and an end condition. Like requirements, they describe a system. But although they most likely they will help determine requirements, they are not requirements themselves. They are more than just a nugget of technical information.

Depending on the actor, a use-case can help describe any level of the system. If the actor is the end-user, the use-case will help clarify and create the highest-level requirements. If the actor is a class, code module, or process, it will help clarify and create how lower-level derived requirements. So a use-case can describe and develop both how a system must behave, and how it will work.

Here is an example; a use case linked to higher level requirements.

A Use-Case
1. The end user opens the door to the aircraft.
2. The end user sits in the seat of the aircraft.
3. The end user press the on button button on the dash of the aircraft.
4. The aircraft engine starts.

Start Condition: Aircraft is off and unoccupied
End Condition: Aircraft is on and occupied.

A Requirement
1 The aircraft shall allow the pilot to turn on and off the aircraft.

But more Useful, a set of Associated Requirements:

1 The aircraft dash shall allow the pilot to turn on and off the aircraft.
1.1 The aircraft engine shall turn on when the on and off button on the dash in the down position.
1.2 The aircraft engine shall turn off when the on and off button on the dash is in the down position.
2 The aircraft shall have room for one pilot.
2.1 The pilot of the aircraft shall weigh less than 300 pounds.
2.2 The aircraft shall have a cushy leather seat.
2.2.1 The cushy leather seat shall cost less than $1000

We can see that

• A use case is different that a requirement.
• A use case helps create requirements.
• A use case can help create any level of requirements.
  

[1]As a side note I have seen cases where folks will refer to a requirement as a "specification" if it has a "satisfies" parent-child relationship, and as a "derived requirement" if it has a "consists of" parent-child relationship. In general I think all systems can be broken down into a requirements hierarchy, and where you draw the line between "what is needed" and "what fulfills" is arbitrary and depends on context.

What were you thinking Intel?

Whenever I see an amazing product driven by an ARM based processor, I continually ask myself why Intel sold off its line of ARM processors (known as XScale) to Marvell. Here is quick recap for those who aren't familiar with ARM versus Intel's x86 based CPUs:

ARM
ARM is not a chip maker, they are a software company. The software they write is a little different though. It is called a Hardware Description Language. This means that its end purpose is not to be interpreted by a machine, but instead to define a machine. Other companies that make computer chips can take the software definition for the ARM CPU core, license it, customize it, then fabricate it. This provides flexibility in what ARM based CPUs are, the end-customer decides what comprises it.

x86
The word "legacy" best describes x86. I was around 10 when I first used an IBM compatible x86 based computer. Since then the processor been upgrading via duck tape and all sorts of complex modifications in order to improve speed but maintain backwards compatibility. The end result is that I can still play the computer games I played when I was 10 on my PC.

Although x86 chip makers (Intel and AMD) over the years have tried to simplify the architecture, x86 processors have to do more "stuff" in order to maintain both backwards compatibility, and compatibility with Windows. This stuff consumes power, which is why you haven't seen anything smaller than netbooks driven by x86. The more power a CPU consumes, the larger the device using it has to be.

Because the desktop PC market has saturated, and smart phones are taking off, Intel really should have kept their ARM processors. They already had an edge in the market; Blackberries, one of the top iPhone competitors, are powered by xScale CPUs. But instead Intel sold off the processor line. They are restricting themselves to netbooks, laptops, and desktops. Why?

Irony

Has anyone ever noticed how ironic the name of the win32 error code #0 is?

Some Ships Leak from the Top

I marvel at those who have the ability to not speak. It is true, Information is Power, and the more you say the more power you give. I think salesmen know this, so knowing when not to speak and what not to say to them is key. The best know how to make you talk.

The first step is being comfortable with the uncomfortable silence. So easy to say, but so hard to do.

An Alternative to SLOC

Awhile ago I was sucked into development of a DoD proposal. One thing they wanted us to address was SLOC, or "Source Lines of Code". The idea is that they judge the level of software effort and complexity by the lines of code there are. There is a general consensus in the software world that this isn't the best idea. IE, if you write a function call like this

if (a==1)

{

_tprintf(_T("Status Report:\n")

_T("Hello!\n"));

}

Your SLOC will be much higher than if you wrote it like this.

if (a==1) _tprintf(_T("Status Report:\nHello!\n");

There are other arguments I agree on, such as smaller/simpler/efficient source code is better than bloated source code that achieves the same functionality.

I thought of an alternative on the drive in to work today that at least addresses the amount of new lines put in your coding standards. What if we looked noPublish Postt at the source code, but the size of the post-compiled binary machine code? In windows, this would be the size of all the EXEs and DLLs that comprise your application. Now granted, this would probably only be useful for uninterpreted languages (ie C/C++ and Assembly). You would also have to examine how much code is statically linked into your executable, so it doesn't get recounted. But at least your processess for assessment isn't based off of how often the development team hit the "enter" key.

A prediction...

Recently I have been watching the Bill Gates and Steve Jobs interview. It is interesting (a couple years later) to see how some of their technology prediction have panned out. Bill Gates has been (and is still) very excited about having a video/touchscreen interface on furniture surfaces around your house. I have always been skeptical of this; there is something old-timey and rustic feeling that makes non-office furniture appealing. I don't see the merging of technology and furniture being consumed by the masses. Steve Jobs was much less specific about what the next step of technology which is very consistent with Apple's secretiveness, and probably wise too.

Funny how while Bill Gates was touting the tablet as the tech device he would be carrying around in the future, Steve Jobs said nothing about tablets. Two years later, Apple releases the iPad. I wonder if Bill Gates will purchase one and carry it around as he predicted.

I'd like to offer a prediction after hearing a report today. I believe that cell phone providers will deprecate the model of selling phone-call minutes and sell only data plans. At first I thought the politics of the wireless industry would prevent this next vital step from happening any time soon. But after hearing how Verizon is allowing free minutes via Skype over their data plan, I now see how much wireless carriers are thinking outside of the box to stay competitive. This also comes amongst the iPad data-only plans.

I have more predictions too! But I will save them for future posts, so this post can ship.