Posts Tagged ‘software requirements’


December 26, 2014 Leave a comment

At the first level of decomposition, a software requirement can be classified as either “functional” or “non-functional“. A functional requirement (FR) specifies a value-added behavior/capability/property that the software system must exhibit during runtime in order for it to be deemed acceptable by its customers and users. A non-functional requirement (NFR) specifies how well one or more behaviors/capabilities/properties must perform.

Req Breakdown

Unlike FRs, which are nominally local, fine-grained, and verifiable early in the project, NFRs are typically global, coarse-grained, and unverifiable until a considerable portion of the system has been developed. Also, unlike FRs, NFRs often have cold, hard-to-meet, numbers associated with them:

  • The system shall provide a response to any user request under a full peak load of 1000 requests per second within 100 milliseconds. (throughput, latency NFRs)
  • The system shall be available for use 99.9999 percent of the time. (availability NFR)
  • The system shall transition from the not-ready to ready within 5 seconds. (Domain-specific Performance NFR)
  • The system shall be repairable by a trained technician within 10 minutes of the detection and localization of a critical fault. (Maintainability NFR)
  • The system shall be capable of simultaneously tracking 1000 targets in a clutter-dominated environment. (Domain-specific Performance NFR)
  • The system shall detect an air-breathing target with radar cross-section of 1 sq. meter at a range of 200 miles with a probability of 90 percent. (Domain-specific Performance NFR)
  • The system shall produce range estimates within 5 meters of the true target position. (Domain-specific Performance NFR)
  • The system shall provide TCP/IP, HTTP, CORBA, and DDS protocol support for interfacing with external systems. (Interoperability NFR)

During front-end system conception, NFRs are notoriously underspecified – if they’re formally specified at all. And yet, unlike many functional requirements, the failure to satisfy a single NFR can torpedo the whole effort and cause much downstream, career-ending, mischief after a considerable investment has been sunk into the development effort.

Since extra cross-cutting functionality (and extra hardware) must often be integrated into a system architecture (from the start) to satisfy one or more explicit/implicit NFRs, the term “non-functional requirement” is often a misnomer. Thus, as the SEI folks have stated, “Quality Attribute Requirement” (QAR) is a much more fitting term to specify the “how-well-a-system-must-perform” traits:


As the figure below illustrates, the “QARization” of a system can substantially increase its design and development costs. In addition, since the value added from weaving in any extra QAR software and hardware is mostly hidden under the covers to users and only becomes visible when the system gets stressed during operation, QARs are often (purposely?) neglected by financial sponsors, customers, users, AND developers. Stakeholders typically want the benefits without having to formally specify the details or having to pay the development and testing costs.

Before And After QAR

It’s sad, but like Rodney Dangerfield, QARs get no respect.

SysML Support For Requirements Modeling

“To communicate requirements, someone has to write them down.” – Scott Berkun

Prolific author Gerald Weinberg once said something like: “don’t write about what you know, write about what you want to know“. With that in mind, this post is an introduction to the requirements modeling support that’s built into the OMG’s System Modeling Language (SysML). Well, it’s sort of an intro. You see, I know a little about the requirements modeling features of SysML, but not a lot. Thus, since I “want to know” more, I’m going to write about them, damn it! 🙂

SysML Requirements Support Overview

Unlike the UML, which was designed as a complexity-conquering job performance aid for software developers, the SysML profile of UML was created to aid systems engineers during the definition and design of multi-technology systems that may or may not include software components (but which interesting systems don’t include software?). Thus, besides the well known Use Case diagram (which was snatched “as is” from the UML) employed for capturing and communicating functional requirements, the SysML defines the following features for capturing both functional and non-functional requirements:

  • a stereotyped classifier for a requirement
  • a requirements diagram
  • six types of relationships that involve a requirement on at least one end of the association.

The Requirement Classifier

The figure below shows the SysML stereotyped classifier model element for a requirement. In SysML, a requirement has two properties: a unique “id” and a free form “text” field. Note that the example on the right models a “non-functional” requirement – something a use case diagram wasn’t intended to capture easily.

One purpose for capturing requirements in a graphic “box” symbol is so that inter-box relationships can be viewed in various logically “chunked“, 2-dimensional views – a capability that most linear, text-based requirements management tools are not at all good at.

Requirement Relationships

In addition to the requirement classifier, the SysML enumerates 6 different types of requirement relationships:

A SysML requirement modeling element must appear on at least one side of these relationships with the exception of  <<derivReqt>> and <<copy>>, which both need a requirement on both sides of the connection.

Rather than try to write down semi-formal definitions for each relationship in isolation, I’m gonna punt and just show them in an example requirement diagram in the next section.

The Requirement Diagram

The figure below shows all six requirement relationships in action on one requirement diagram. Since I’ve spent too much time on this post already (a.k.a. I’m lazy) and one of the goals of SysML (and other graphical modeling languages) is to replace lots of linear words with 2D figures that convey more meaning than a rambling 1D text description, I’m not going to walk through the details. So, as Linda Richman says, “tawk amongst yawselves“.


1) A Practical Guide to SysML: The Systems Modeling Language – Sanford Friedenthal, Alan Moore, Rick Steiner

2) Systems Engineering with SysML/UML: Modeling, Analysis, Design – Tim Weilkiens

Yes I do! No You Don’t!

September 3, 2010 Leave a comment

“Jane, you ignorant slut” – Dan Ackroid

In this EETimes post, I Don’t Need No Stinkin’ Requirements, Jon Pearson argues for the commencement of coding and testing before the software requirements are well known and recorded. As a counterpoint, Jack Ganssle wrote this rebuttal: I Desperately Need Stinkin Requirements. Because software industry illuminaries (especially snake oil peddling methodologists) often assume all software applications fit the same mold, it’s important to note that Pearson and Gannsle are making their cases in the context of real-time embedded systems – not web based applications. If you think the same development processes apply in both contexts, then I urge you to question that assumption.

I usually agree with Ganssle on matters of software development, but Pearson also provides a thoughtful argument to start coding as soon as a vague but bounded vision of the global structure and base behavior is formed in your head. On my current project, which is the design and development of a large, distributed real-time sensor that will be embedded within a national infrastructure, a trio of us have started coding, integrating, and testing the infrastructure layer before the application layer requirements have been nailed down to a “comfortable degree of certainty”.

The simple figures below show how we are proceeding at the current moment. The top figure is an astronomically high level, logical view of the pipe-filter archetype that fits the application layer of our system. All processes are multi-threaded and deployable across one or more processor nodes. The bottom figure shows a simplistic 2 layer view of the software architecture and the parallel development effort involving the systems and software engineering teams. Notice that the teams are informally and frequently synchronizing with each other to stay on the same page.

The main reason we are designing and coding up the infrastructure while the application layer requirements are in flux is that we want to measure important cross-cutting concerns like end-to-end latency, processor loading, and fault tolerance performance before the application layer functionality gets burned into a specific architecture.

So, do you think our approach is wasteful? Will it cause massive, downstream rework that could have been avoided if we held off and waited for the requirements to become stable?

Functional Allocation III

The figure below shows the movement from the abstract to the concrete through a nested “allocation” process designed for big and complex products (thus, hackers and duct-tapers need not apply). “Shalls” are allocated to features, which are allocated to functions, which are allocated to subsystems, which are allocated to hardware and software modules. Since allocation is labor intensive, which takes time, which takes money, are all four levels of allocation required? Can’t we just skip all the of the intermediate levels, allocate “shalls” to HW/SW modules, and start iteratively building the system pronto? Hmmm. The answer is subjective and, in addition to product size/complexity, it depends on many corpo-specific socio-technical factors. There is no pat answer.

Levels Of Abstraction

The figure below shows three variations derived from the hypothetical six-level allocation reference template. In the left-most process, two or more product subsystems that will (hopefully) satisfy a pre-existing set of “shalls” are conceived. At the end of the allocation process, the specification artifacts are released to teams of people “allocated” to each subsystem and the design/construction process continues.   In the middle process, each SW module, along with the set of shalls and functions that it is required to implement is allocated to a SW developer. In the right process, which, in addition to custom software requires the creation of custom HW, the specification artifacts are allocated to various SW and HW engineers. (Since multiple individuals are involved in the development of the product, the definition of all entity-to-entity interfaces is at least as crucial as the identification and definition of the entities themselves, but that is a subject for another future post.)

Allocation Variations

Which process variation, if any, is “best”? Again, the number of unquantifiable socio-technical factors involved  can make the decision daunting. The sad part is, in order to avoid thinking and making a conscious decision, most corpo orgs ram the full 6 level process down their people’s throats no matter what. To pour salt on the wound, management, which is always on the outside and looking-in toward the development teams, piles on all kinds of non-value-added byzantine approval procedures while simultaneously pounding the team(s) with schedule pressure to compplete. If you’re on the inside and directly creating or indirectly contributing to value creation, it’s not pretty. Bummer.

%d bloggers like this: