Question

What are software requirement tools? What are the two major categories of these requirement tools? Write some key features that must be considered while choosing the requirement tools? Also, give some real-world examples for some of these tools.

NO HANDWRITING PLEASE... THANK YOU.

Answer 1

The software requirements are description of features and functionalities of the target system. Requirements convey the expectations of users from the software product. The requirements can be obvious or hidden, known or unknown, expected or unexpected from client's point of view. The tools which are used in software requirement is known as software requirement tools.

Tools for dealing with software requirements. Its classified into two categories:

1) modeling tool:-

Modelling tools are basically 'model-based testing tools' which actually generates test inputs or test cases from stored information about a particular model (e.g. a state diagram), so are classified as test design tools.

2) traceability tool:-

It have the ability to trace work items across the development lifecycle. It's used to keep track of what's going on in the development lifecycle — and show what's happened. Achieving regulatory compliance is a common purpose for traceability in software engineering.

There are some key features that must be considered while choosing the requirement tools are:-

1. Understanding Your Needs:-

Do you have a clear definition of what you are looking for? If you are not sure, you're not ready to buy.

2. Flexible Process Support:-

Is the tool flexible in supporting processes and procedures? Unless you are a start-up, you probably have some methodology in use already. One common approach is to look for a software solution that can support your current process, however, one of the probable reasons you are looking for software support is that things are not going so well, in which case you should also seriously consider reviewing and improving your process.

3. Requirements Formats:-

Are multiple requirements formats supported? You might easily imagine the need to label various requirements differently using textual attributes, but it is almost certain that textual requirements statements will become insufficient at some point.

4. Change Management:-

Anyone who thinks that their requirements will remain unchanged is in serious denial. Even the most rigid of government procurement projects is going to change more than anyone would like. Consequently, an important question must be, How well does the tool support change? Change has two perspectives: looking forward, and looking backward.

5. Linking Requirements to Tests:-

How well is the requirements function integrated with the testing function (and even defect tracking)? The relationship between requirements and tests is a subject worthy of greater and more serious discussion than we are able to give here, but what we can say is that this relationship is the most critical of all. Without it, not only is the project likely to fail, but worse, you won't know it has failed until you have delivered.It should be easy to create links between requirements and tests as well as to derive tests quickly and easily, directly from the requirements. A good software solution will support both ends of that equation equally well. Avoid the requirements management tool with some 'tacked on' test capability and, equally, beware the test management tool with some rudimentary requirements capability added to get the 'tick-in-the-box' for on-paper product comparisons.

6. Flexibility of Relationships:-

Traceability is a 'must have' for any decent requirement management tool, but it is rarely simple. How flexible are the traceability features? Ideally, the possible relationships would be arbitrary, that is, any piece of information should be linkable to any other piece of information. That is not to say the tool shouldn't provide relationship rules, but we want control of those rules and not have the software limit the ability to create whatever traceability we see fit.

7. Collaboration:-

How well does the software support collaboration? It is highly inefficient to rely on email, text messages or even worse, group meetings, to facilitate the communication of team members in real time. Information may be out of context and afterward, no reliable record of the interchange exists, leaving other team members in a vacuum with no good way to discover what is going on. Look for tools that support some kind of communication, even if it is only notification of change or allocation of tasks.

8. Product Roll-out

Once you have selected your tool of choice, then comes the hard part; putting it to work. A product may look simple and easy to use in a demo, but then it's being used by a tool expert. During the roll out of your new product, you will have few, if any, experts on your project.

Software requirement is a functional or non-functional need to be implemented in the system. Functional means providing particular service to the user.

For example, in context to banking application the functional requirement will be when customer selects "View Balance" they must be able to look at their latest account balance.

Software requirement can also be a non-functional, it can be a performance requirement. For example, a non-functional requirement is where every page of the system should be visible to the users within 5 seconds.