4

I have a specific case for this inquiry, but hopefully it can be generalized to anything else.

I'm working with an aircraft simulator and have been tasked to implement a module whose goal is to improve the performance, if you will, of the existing module. After reading up about how to write proper requirements (and there's company procedure and all that), I'm still a little stumped about how to go about writing a requirement.

The good news is that there's data from the aircraft being simulated, so for testing purposes there's at least some real data to compare to. And I'm aware of the FAA document AC-120-40B, but I don't believe we're trying to approach the FAA requirements since we're not trying to get FAA certification (It'd be nice to get there, but that hasn't been a stated goal)

Still I don't think "The [software component] shall perform better than [component] from versions prior to [version] when compared to [real data]" would cut it as a good requirement.

I suppose I'm concerned with what makes something objectively better. The FAA doc does have some scenarios that cover this module, but then there might be someone who goes "but what about X scenario!?"

And then I feel like I'm trying to prove or disprove some substance causes cancer in a variety of situations.

For others with this inquiry, the project does not have any existing performance requirements for the module.

Improve this question
3
  • 1
    Do you have requirements that are traced to the existing implementation?
    – Thomas Owens ♦
    Jun 1, 2016 at 16:20
  • Strangely enough, there's nothing concerning the aircraft's performance, just features. e.g., "it will do this" and not "it will perform within x and y"
    – anon
    Jun 1, 2016 at 16:29
  • 1
    By "performance" do you mean the latency/throughput/etc of the program, or the accuracy of the simulation? ("performance" typically means the former, but your phrasing in the question makes me think you mean the latter)
    – Tin Wizard
    Jun 1, 2016 at 21:57

3 Answers 3

Reset to default
10

To start, I'd say you don't have sufficient information to write the requirements. Your task would be to gather specific details. When you're tasked to improve performance, the first thing you should probably do is measure what the current performance is and record these numbers.

Then, you should decide together with the business what the target is. If you have this, you can write out the requirements. Here are a few examples:

  • Component X should calculate Y within 2 seconds
  • The module should have a throughput of at least 100 requests/second

Doing this makes the subjective "improve performance" more objective and measurable. It also prevents later discussions where some say it's gotten worse, some say it stayed the same and others say it has improved. With real data and benchmarks you can prove the impact the changes had.

Improve this answer
7
  • I can run the old versions to gather data, but I'm concerned about how to go about it in a general way. Let's say for example the real aircraft turns at a rate of 5 RPM, but the sim can only do 2 RPM given the same conditions. (though I guess in this case, the FAA does have a clear general requirement of some tolerance vs. the real aircraft)
    – anon
    Jun 1, 2016 at 17:02
  • Wanted to make another comment to start another thought. Would it be best to isolate basic characteristics of what the module is supposed to do that covers all the scenarios as much as possible, and then write requirements around that?
    – anon
    Jun 1, 2016 at 17:06
  • 2
    @Shuffy For your first comment, the "right" thing to do is to write the requirement to describe intended behavior. When you review the requirement against the design constraints of the environment or do some prototyping or modeling, you will find that this requirement is not achievable. You then go back to the stakeholders and work with them to determine what to do, updating the requirement appropriately. Your requirements management process should account for capturing the rationale behind requirements or requirement changes.
    – Thomas Owens ♦
    Jun 1, 2016 at 17:24
  • Thanks for the insight. I should get over my fear of not getting it right the first time at this rate, just get something that looks reasonable (but still well defined and verifiable).
    – anon
    Jun 1, 2016 at 17:58
  • 1
    Re, "...makes the [requirement] more objective and measurable." See: en.wikipedia.org/wiki/SMART_criteria
    – Solomon Slow
    Jun 1, 2016 at 20:49
5

I see two cases: you have requirements for the software or you don't.

In your particular case, you don't have performance requirements, but you do have functional requirements. You should update your requirements specification to add performance requirements and associate those with specific pieces of functionality. When you're writing these performance requirements, they should still adhere to the same general quality guidelines as functional requirements, specifically be complete, consistent, unambiguous, traceable and verifiable.

Instead of comparing the performance to the old system, simply treat them as new requirements. Specify things like maximum time to respond to an input, minimum data throughput, intervals between outputs (upper and/or lower bounds).

Examples of a good performance requirement is:

The {component} shall respond to {input} within 5 milliseconds.

The {component} shall {output} at 10Hz.

When organizing my requirements, I typically group performance and functional requirements together. Generally, a performance requirement is associated with a particular function of the system, perhaps when the system is in a given state. My other groups are design constraints (design decisions that currently exist and must drive requirements), interface requirements (hardware, software, data exchange, user interfaces), and quality attributes (the -ilities, security, etc.)

For completeness, in the event that you didn't have a requirements specification at the appropriate level, you would simply begin with the new requirements as I described above in a specification. If you had sufficient time, you could go back and write functional, performance, and other quality attributes for the system and other components and trace test procedures to requirements. You would end up with scenarios that are not covered by requirements, but that's the nature of dealing with undocumented requirements to begin with.

Improve this answer
2
1

I have some background in requirements engineering, though for these kind of unsharp requirements it is in my opinion required to take a different view on on the requirements. There are various methods for requirements elicitation, grouping, analyzing, refining etc.

There is however a common pattern to most methods and practices: You need to take different views and perspectives to the same requirements, in such way that your stakeholders (and yourself) understand and agree on requirements. You're not yet in that state, thus you need to get more info - or make assumptions.

In the mid-size company I'm working for right now, where there is little knowledge about requirements engineering in general, I choose a simple 3-step model to discuss my assumptions and define / agree requirements with the stakeholder:

Business Goals

Business goals are the most important requirements. They drive everything, and give you reason (and your company money or other value) for any development task. Business goals need to answer the question: Why are doing this? => According to what and how you describe your situation, it seems to be unclear to you and maybe also to the business guys in your company.

Is it that some important customer just complained that the joystick is too slow, and you'll loose him if that isn't improved? Or is it your competitors have an overall more responsive system, and you need to keep up with the competition? If for example the latter is the case, you'd have to compare your own system against the competition, and derive technical requirements from this comparison.

I'd put a question mark to the stated goal "make the system faster". Somebody had probably good intentions requiring you to do so, but it should be your job as "requirements engineer" to make assumptions and make reason from a business perspective.

Depending on where you work and how your organization looks, it may or may not be a good idea to ask directly for a reason or business goal to your task. That can make a negative impression. Rather, make a clearly worded own assumption for the business goal, and make it clear that your assumption will be what drives your technical requirements analysis and definition. Often enough this will indirectly lead to debates in the business department, because it's likely the business goal isn't really that clear. Which is then a business task to refine the goals.

Even though you're not a requirements engineer officially (thus I put that in quotes above), you should take that position to some degree. Because a) somebody may put blame on you later for whatever reason, because it's easy to claim that you didn't understand the task with no further background or actual business goal provided. The business guys know that. Though that's about playing tricks, but knowing these things make you a part of the solution also.

Product requirements

Product requirements should give answer to the question: What needs to be done. It should also fit to the product vision.

That part seems defined (implement or reimplement some module within your product). Though without background, I do not understand the reason. Probably you know. If not, you should also ask for the broader picture, and how your changes are supposed to improve the product.

System requirements

Finally, at the very last and from business perspective least important (not for you of course), system requirements answer the question: How should it be done / implemented?

I believe you know how to define this. And this will be the least problem for you, after you gathered business and product requirements.

You also don't necessarily need to prove or disprove anything - just give well worded and clear own assumptions. Give your assumptions together with your defined requirements to your boss and your stakeholders. Agree with them on both, your assumptions as well as your defined requirements.

It's the job of whoever "owns" a requirement (or has a stake in it) to disprove you'r assumption. Provide your assumptions and requirements to all it may concern, and your chances that it will be a success will significantly increase.

Improve this answer
3
  • 1
    Cutting through all the jargon, (1) somebody must have asked for something to be done, (2) somebody else must have agreed to spend the company's time and money doing it (or at the very least, to spend time and money attempting to do it). If there isn't a documentation trail that leads back to that decision and/or those two people, it probably doesn't matter what you specify - the company's software development process is hopelessly out of control anyway. If there is a trail, even in the worst case it should point you in the right general direction, even if it's not very specific on details.
    – alephzero
    Jun 1, 2016 at 20:56
  • +1 Traceability back to Business goals, -1 (system) requirements don't deal with the solution domain. They don't tell "How should it be done/implemented"
    – Kaan
    Jun 1, 2016 at 23:00
  • I can't downvote, but as I also said in my introduction: there exist many different concepts. Compare Volere with REM, to ReQMAN to Ebert, and others. You'll find variations in the namings and interpretations. I keep it with Ebert for breaking it down into three digestible parts. Though he calls System Requirements "Component Requirements". You'll find the questions asked for each domain exactly this way (why, what, how should it be done). Look closely to other RE concepts, and you'll find common patterns to deal with requirements - but changing names and sometimes varying interpretations.
    – benjist
    Jun 1, 2016 at 23:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.