System and Software Requirements - SPICE & IEEE

[ebeb]

Hi!

During my last projects I have come across several best-practices in requirements engineering. But now, I wanted to get the whole process of RE a little bit more structured.

Let me briefly introduce my problem:

I currently develop requirements for a client/server system. To see how industry standards handle RE, I read a book about SPICE. I tend to adopt some of the processes for my project. In detail, amongst others, SPICE recommends the following engineering processes:

ENG.1 Req. Elication
ENG.2 Sys Req. Analysis
ENG.3 Sys Architectural Design
ENG.4 SW Req. Analysis
ENG.5 SW Design
...

I'd like to use this structure for deviding my EA project in to models. But actually I'm not really sure if that makes sense plus I don't know where to put what and how to avoid redundancy.

I read somewhere, that in a SW-only project, ENG.2 + ENG.3 are not necessary. So, even though we don't manufacture hardware, we might use specific devices and need to specify special hw and environmental constraints. To make sure, I read the IEEE standards 1233 (system requirements) and 830 (SW requirements). As far as I can say, the SyRS contains "capabilities, conditions and constraints" but also functional product requirements ("What should the system be able to do?"). Moreover, I read that use cases could be used to define interfaces. That would mean, in ENG.1 the high-level customer requirements will be gathered and defined, ENG.2 covers more general system related stuff like performance, security, durability etc plus use cases and detailed requirements. ENG.3 would include sw and hw partinioning such as component model as well as user interface design.
Thus, ENG.4 would include only software-related requirements that can be directly traced down to software modules.

Am I right, so far? If not, please feel free to correct me.

As I stated before, I'd like t avoid redundancy. SPICE recommends 3 requirements specs, Customer Requirements, System Requirements and SW requirements.
Could somebody explain the differences or give a short example how I would get from a customer requirement to a system req. and then to SW req.

Currently, I tend to having only two R specs, the customer requirement (actually requirements from the product management), then I performed a use case analysis and then I deduced detailed functional and non-functional requirements from which I could start designing the software. So I am not really clear about how to divide what I have into a SyRS and a SRS or if I don't need to divide but rather to add something i don't have already. Or is the list of sys req. almost equal to the list of SW req.? As you can see I am a bit confused...

Any comments are welcome!

Thanks, Jan

[beginner]

I would say this is a needle stack where you have to find the hay. At least for me as at my current customer we do have exactly the same problem. They are building an embedded system where parts are safety relevant. In those cases we need to stick to the procedure you detailed above. In fact I can't talk of experience but only about the current state.

Our approach (we're trying to introduce EA/SysML as basis since a couple of months) is a mixture of MDA and RUP. The CIM contains the user requirements which we import from DOORS (though that is!). They are sorted in functional groups so we have a structured requirement spec. A large part of that work is directly done in DOORS and we only shadow that to EA.

Further we create a draft design in the CIM thereby synthesizing the Use Case and identifying the Actors (both placed in the PIM). Where necessary a pre-sketch of the Use Cases as Business Use Cases is done. We're not sure how to cope with that. Probably SPEM or some other profile would be better?

Along with the UC synthesis a draft design of the system devices is created. This and the UCs build the stage before the SyRS/SRS.

We are now in a state where we try to identify the artifacts for the SyRS/SRS and have a rather complex profile already. Of course the customer had and still has a lot of paper based documentation targeting to SyRS/SRS but honestly speaking nobody had a real idea what should go into these documents. So they are in a rather - let's say indifferent - state.

Another thing we're struggling with are features. I read about FDD and part of that is very nice, but too many people need to carry that kind of concept. And if management does not concur it's of no real value. However, the concept of features as having some "blurry" description linked to work packages made sense and tends to be accepted. We'll have to see where that will lead.

Hmm. There's much too much to say and work's piled up here. Would be nice to have a chat over an afternoon.

b.

[ebeb]

Would be nice to have a chat over an afternoon.

I'm in!

I mean, there are some common practices, and most system engineers with a little experience would probable adopt a lot of them instinctively. However, if you start thinking about how to do it the right way everything gets more and more complicated. There are hundrets of standards, recommendations, opinions and once you try to apply them to your project you get stuck and ask yourself seriously "why did I even start...?".

I read the IEEE standards and as a result, I added a few diagrams to my model because I though it a good idea. But its sometimes hard to decide if its either redundant or simply useless.

E.g., I worked for huge international engineering company. They had these fance Word template for everything. Every document always contained introduction chapters like "Overview, Scope etc.". And I bet, no one every read them after they were written. So they were redundant AND useless.

EA is indeed very helpful to avoid redundancy but it (obviously) can not help to structure you project. At first, I adopted a few structures of the example project but until today, I reoganzied everything a couple of times because of various reasons.

Ok, I'm tired (physically, not mentally) I'd appreciate if this could turn into a little discussion rather than a plain Q&A.

I know this is not a EA specific issue but I guess there in this forum there are quite a few people dealing with similar problems and might already have found an answer

Cheers,

Jan

[beginner]

You are in a maze of twisty little passages, all alike. I wouldn't dare to ask whether you work for the same company It's been a hard week and it's not over yet. However, I'll try to be back next week to start the discussion.

Have a nice weekend.

b.

[Geert Bellekens]

I agree, it is could become very complicated to create a modelling method that suits your specific needs, and leaves out the stuff that you don't need. (that last part is probably the hardest).

But how do we deal with things that are complicated? Create a model!
And this is often forgotten in the guidelines of modelling methods I've seen at different clients over the years.
Sometimes the only documentation of the modelling method is a set of MS Word templates that should be filled in...

I think creating a Meta Model is the first step in getting the modelling method analysed and documented.

I recently published a set of articles about this subject, and I would love your feedback on them:

Modelling Method
Modelling Quality
Modelling Tooling

Geert

[son-of-sargasso]

As I stated before, I'd like t avoid redundancy. SPICE recommends 3 requirements specs, Customer Requirements, System Requirements and SW requirements.
Could somebody explain the differences or give a short example how I would get from a customer requirement to a system req. and then to SW req.

It's been quite a few sleeps since I last read SPICE but it appears from what you said here and IIRC:

• Each customer requirement could be expressed with the prefix "The customer wants to..."  as in "The customer wants to save costs by (somehow) improving the process by which orders created by the sales staff are costed, approved and processed for delivery."  No mention of systems and more importantly no requirement expressed as a design.  In order to confirm that we, i.e. the solution provider and the customer, both have an equal understanding of the situation and the need we will jointly define a specification of these Customer Requirements.  This will be documented by following the ENG.1 and ENG.2 processes and will involve producing some models of the Customer's domain - say a business workflow model or two, maybe some business rules, a domain model that defines the business objects etc.
  [BP Tip] Sometimes during this exercise it becomes apparent that there is a difference between how the customer imagines their business operates and how it really does.  It is important to arrive at a level of detail in the elicitation process that eliminates this difference.  This might entail creating some "throw away" models i.e. ones that are used in the process but do not appear in the specification.
  
• System requirements are those more familiar "The system shall's".  Each one of these defines how the solution should address the Customer Reqs.   This might include some technology requirements, some high level software requirements and maybe even (or more likely, probably) some process changes.  Although SPICE calls these "System" requirements, they are more correctly IMO "Solution" requirements.
  [BP Tip]  During the elicitation of these we might start to uncover some of the "hidden" business requirements such as things about user authentication, B2B problems or changes that would have an impact on the viability of solution designs.  
  At this time, we come up with a "Vision" of the solution.  IOW an idea of how the business will operate in the future.  This is what we are documenting and agreeing with the customer.  Again this might contain a number of different models, it depends on the situation.
  
• Software requirements refine and consolidate the solution requirements for the software components of it.  They specify the "contract" for the SW architects, SA's, DBA's and code cutters.  By the time we are concentrating on developing this spec, we have a pretty clear idea of the solution.  
  

One prime concept is that these specs are not developed in a stepwise process,  parts of each crystalise over time.  If the customer requirement is for a "computer system to..." then SW requirements will most certainly arise early.  Similarly development of requirements does not take place before, nor in isolation of, any solution design work.

UML (the technique) and EA (the tool) provide a pretty good mechanism for handling this concurrency.  Different models contain the different "species" of requirements.  There is no law saying you have to do one before the other.

UP and other methodologies specify which species should reside in which document, why the document should exist and who is the target audiences.

On the topic of template documents and the seeming duplication of effort of certain sections, I have found value in looking at the place of the document in the history of the solution delivery project.  For example, the "Objectives" section is best used to talk about this version of the document describes the blah blah, where blah blah might be "the business processes of interest existing before the project was initiated", "the business processes that will exist after the completion of the project" or even "the business processes that will be employed between Release 2 and 3 of the system".  This is because each document is actually a snapshot.  It will not change whereas the business, the requirements, the solution and the software will change over time.  A lot of the "hygiene" sections of the documents become much more meaningful, important to read and valuable when this approach is used.

Gotta go spray the trees again.

hth
bruce

[son-of-sargasso]

beginner,

I'd like to have an afternoon chat too.  But the topic would be "on getting past the volcano" 8-)

bruce

[Geert Bellekens]

The only problem with an "afternoon chat" is to define "afternoon", given that the different participants may come from all over the globe :-/

Geert

[beginner]

...
Currently, I tend to having only two R specs, the customer requirement (actually requirements from the product management), then I performed a use case analysis and then I deduced detailed functional and non-functional requirements from which I could start designing the software. ...

What is your role in the project that you express this as a personal wish? Do you have authority to decide which way to go?

b.

[ebeb]

What is your role in the project that you express this as a personal wish? Do you have authority to decide which way to go?

Yes I have. Actually I'm a systems engineer. But, we a very small start-up company. So I am in the lucky but difficult position to descide which way to go I have quite some experience from previous projects in other rather huge companies. What I learned from that is that I don't want to do it the same way. So currently I'm searching for the right direction.

Jan

[ebeb]

But how do we deal with things that are complicated? Create a model!
And this is often forgotten in the guidelines of modelling methods I've seen at different clients over the years.
Sometimes the only documentation of the modelling method is a set of MS Word templates that should be filled in...

I think creating a Meta Model is the first step in getting the modelling method analysed and documented.

I recently published a set of articles about this subject, and I would love your feedback on them:

Hey Geert, thanks for your reply. It is a in deed a good idea to create a Meta Model that can be linked to certain business and engineering processes. EA is a good tool to do that!

Moreover, I read your articles and they provide very detailed and useful information what people have to know about models and what they need to take care of when creating one.

But I think in my case, this is still a step ahead. I'm lacking in the information I want build the model with. If I had this information, I could use your articles to create a good self-contained model.  :-/

[Geert Bellekens]

Jan,

I think just because you are in the unique situation that you don't have a modelling method yet that you should take this opportunity to start with a metamodel, and a decent method documentation.
I guess the first version will be a bit sketchy, and will change a lot, but the metamodel can advance together with your understanding of what you actually need to model the system under construction.

It is always easier to start fresh then it is to have to reverse engineer an existing method based on the fragmented documentation and examples from the real life models.

Geert

[ebeb]

@son-of-sargasso

Hey Son

thanks for your detailed description!

But I have to admit that it is still not easy to apply that to my project.

At first, one general question: I saw some elemtets called "feature" in EA. Is this still necessary or covered by the requirements which define kind of requirered features as well (from my point of view).

Lets assume we have a little project (Just imaginary, doesn't have to make sense). The customer want "accessibility" of the client.

So we define "client accessibility" as the high level customer requirement.

Now, the system or solution requirements could then be "accesible via GPRS", "accessible via SMS", "accessible via device interface" and whatever.

What now?

The software requirements? I have a little feeling, that the requirements above are almost sufficient to handle it over to the software developers except for some additional non-functinoal SW requirements that could be added. Everything more detailed could be covered in the software design spec where the developer describes how to realize the requirement.

I hope you understand my problem a little better. If'd seperate into three levels of requirements I jsut don't know what write there. It's like I would have to do and I do it and that would in turn result in redundant information.

And when I read the IEEE system spec standard, I get the feeling that they also don't use a list of system requirement. I think their idea is to have high-level requirements. The system spec only characterizes the system and its constraints. Then, the SW req spec has a detailed list of those requirements.

If I'm wrong, please correct me!

Jan

[ebeb]

Jan,

I think just because you are in the unique situation that you don't have a modelling method yet that you should take this opportunity to start with a metamodel, and a decent method documentation.
I guess the first version will be a bit sketchy, and will change a lot, but the metamodel can advance together with your understanding of what you actually need to model the system under construction.

Yes. I am and always was the kind of guy who identifies non-optimal processes and I was always willing to spend time to do it right even it was for others. But during my previous jobs, I was always told that this is not my job and there others who are payed to do it. So I was bound to work with a non-existing meta-model and bloated processes that were once designed for a different department and a stack of dozents of Word templates which had to be filled with useless words just for the sake of being filled and once that happened they could report that we have reached a new milestone.  

[ebeb]

If'd seperate into three levels of requirements I jsut don't know what write there. It's like I would have to do and I do it and that would in turn result in redundant information.

And when I read the IEEE system spec standard, I get the feeling that they also don't use a list of system requirement. I think their idea is to have high-level requirements. The system spec only characterizes the system and its constraints. Then, the SW req spec has a detailed list of those requirements.

I need to quote my self I just read the SPICE book again and found something useful within the hints for assesors:

It recommends to seperate into System and Software requirements but (and this is the interesting part) in many projects, it is not reasonable to separate the System and SW req. Both will be covered by one document at system level including use cases.

The base practice 1 requirements of ENG.4 (SW requirements) are completely met if it is proven that functional and non-functional  requirements are specified unambiguously and reasonable for the complexity of the system.

That means, that, as I explained before, I can define customer requirements as ENG.1 and combine ENG.2, ENG.4 (and maybe even ENG.3) in one document as I hoped and still comply with SPICE!

That's good news and I can leave off work satisfied  8-)

BTW: A chat would really be complicated since some are from down under, some from the US and some from central europe.

Maybe we should open a Wave....