Secrets of Successful Software Requirements

Although most companies do some form of requirements, there is often a lack of understanding as to exactly why the requirements need to be created and the level of detail that should be included in the requirements.

Software is always created to solve a need for a client. The client may be an internal client, an external client, or even the general public. Detailed requirements are important to ensure that a program correctly and fully addresses client’s needs.

Detailed requirements make initial development easier and faster because the developers know exactly what should be developed and do not need to make their best guess at the functionality to be implemented or delay development by creating requirements during development. Giving the developers accurate requirements will also result in less rework at the end of development because the stakeholder’s requirements will have been implemented correctly initially and will not be arrived at through trial and error.

A project manager can use the detailed requirements to create accurate timelines and give correct estimates to the client. This ensures that stakeholders are completely aware how long development will take so they can adjust the scope of a project or proactively add resources if necessary.

Finally, testers can use the requirements to create test plans while development is ongoing rather than waiting until development is complete. The requirements give them information about what the program will do so there cannot be disputes between developers and testers as to what the programfunctionality should be. High quality requirements also describe problem paths that may need additional testing.

Even though highly detailed requirements make development easier in future phases, this is not always possible due to time constraints imposed by the client or market conditions. With this in mind, let’s look at somesecrets to improve your requirements process even under tight deadlines.

Secret #1 – Include Use Cases:

Use cases look at the requirements from the standpoint of an end user working with the program and how the program responds to the user’s inputs. At its simplest level, a use case can be thought of as a play where the end user is one actor and the program is another actor. These two actors then have dialogs which explain the interactions between the actors. More complicated scenarios can have additional actors including other programs, other types of users, and even hardware. Use cases have proven to be very easy to read and understand even for non-technical clients.

Each use case explores what happens when something goes wrong in addition to the “normal” interactions. The exploration of these failure conditions is very important because these cases are the most difficult to code and can cause the most amount of testing. Traditionalrequirements often ignore these cases. It can be helpful to have developers and testers both think of additional possible failures in a use case so they can be fully documented in therequirements.

Use cases do not provide a complete picture of the system though. A technical specification should also be included in the requirements to detail formulas and routines that take place behind the scenes.

Secret #2 – Prototype Screens with a Design Tool:

A user of the program only interacts with a program through the user interface so it makes sense to spend a significant amount of time duringrequirements to ensure that the user interface makes sense, that all functionality is included, and that the most commonly used functionality is easily accessible. The easiest way of doing this is using a screen prototype.

There are a variety of methods of making screen prototypes which range from simply drawing the interface with a pen and paper to building “working” prototypes in a higher level language like Visual Basic which allows rapid screen design. However, each of these extremes has serious drawbacks. A pen and paper prototype does not allow users to interact with the prototype and it is more difficult to change. A “working” prototype done in a programming language like Visual Basic can lead the client to believe that the program is nearly complete and that development should not take very long or it can lead the client to believe that changes to the prototype will be costly making them reluctant to make necessary suggestions to improve the program.

Between these two extremes lies screen design applications which allow you to draw the screens and model interactions between screens. High quality prototyping tools allow you to enter sample data and allow users to move between screens by pressing buttons so they can easily understand the interface and itsfunctionality . Most prototyping tools produce the final output in an HTML format so they can be easily shared even if a client is not in the same office whererequirements are being developed.

When looking for a prototyping tool, make sure to select a tool which is easy enough to use that you can easily prototype screens while your customer is in the room. This will allow you to brainstorm and make changes to the screens without delays. A prototyping tool should already have common controls already defined to maintain design standards and improve the appearance of your screens. Being able to enter sample data in each screen can allow the customer to pinpoint areas that may be incorrect.

Secret #3 – Work Directly with End Users:

When designing a new application or making revisions to an existing application, there is no substitute for the direct experience that end users have. An end user can give immediate feedback on your design to point out awkward or incorrectfunctionality. They also help to ensure that all controls are logically placed for the most efficient use of the system.

Using an interactive prototyping tool allows you to walk a user through the interface or even allow them to work directly with the prototype so they can quickly suggest improvements. As use cases are being developed, it is a good idea to walk users through the use case to ensure that the use case is well thought out and that allfunctionality is captured both in the use case and the prototype.

Secret #4 – Do Iterative Requirements Development:

When you create requirements, it is important to develop the requirements in multiple stages. For example, you may want to do a general layout of the program and create higher level use cases in the first session to get a feel for the overallrequirements . In the next session(s), you can focus on each key feature to ensure that the normal paths are all defined in the use cases and further refine the prototypes. In the next session(s), you can attempt to define all of the error conditions which can occur and update the prototypes as necessary. The final sessions should review all work previously done to ensure that allrequirements are clear and complete. At each stage, you should not be afraid to revise work done in a previous step because getting the requirements correct will ultimately save time in the more costly development and testing stages.

Secret #5 – Place Requirements Documents under Change Control:

With all of the time spent on generating clear requirements, it is very important to make sure that all of the requirements documents are included in your change control system. This includes use cases, screen prototypes, technical specifications, and any other documents used to define therequirements.

Conclusion:

we have explored various secrets to make your requirements process successful and ensure that your clients are satisfied with the resulting program even under tight deadlines. At the start of your next project, make sure you have the proper tools in place for a successfulrequirements iterations including a prototyping program, a tool to write use cases, and a version control program. These tools do not have to be expensive, and they will help to get yourrequirements right and schedule under control.

Accurate Software Testing Services at Affordable Testing Rates

Hi-Tech Software Testing Services is a fast growing software testing company in India. Save up to 40% to 60% on your cost by outsourcing your software testing requirement to us.

Hi-Tech Software Testing Services is a fast growing software testing company in India. Our software testing company is dedicated to providing professional software testing services in India. A Hi-Tech Software Testing Services is well-known name in software testing industries. We are famous for high quality, top accuracy and time bound software testing services. Save up to 40% to 60% on your cost by outsourcing your software testing requirement to us.

Hi-Tech Software Testing Services offers a standard software testing and quality assurance services across the entire software life cycle. Our software testing services includes formulating the test plan and test cases, execution, defect reporting, defect analysis, risk assessments and recommendations. We use neat and clean approach in software testing process to fulfill your exact requirement. Our testing methodology has helped us to minimize project risk and streamline testing releases. Our software testing services will ensure that customer’s software is bug-free, stable and works flawlessly on a variety of platforms.


Various types of software testing involved in this service are:
• Functionality Testing
• Regression testing
• Performance Testing
• Compatibility Testing
• Usability Testing
• GUI Testing
• User Acceptance Testing

The process of QA at Hi-tech Software Testing Services is carried out by a very distinctive Quality Analysis team. . We have a vast experience in software testing field. We offer a standard software testing and quality assurance services across the entire software life cycle.

Our software testers do software testing in varied functional domains based on the given requirement. We have leveraged our testing experience in different platforms such as PHP, Java, .Net, ASP.

Outsource software testing work to us NOW and save up to 40% to 60% on software testing rates.

Test Case Development

 
A test case is a detailed procedure that fully tests a  feature or an aspect of a feature. While the test plan describes what to test, a test case describes how to perform a particular test. You need to develop test cases for each test listed in the test plan.

General Guidelines

As a tester, the best way to determine the compliance of the software to requirements is by designing effective test cases that provide a thorough test of a unit. Various test case design techniques enable the testers to develop effective test cases. Besides, implementing the design techniques, every tester needs to keep in mind general guidelines that will aid i n test case design:

a. The purpose of each test case is to run the test in the simplest way possible. [Suitable techniques - Specification derived tests, Equivalence partitioning]

b. Concentrate initially on positive testing i.e. the test case shoul d show that the software does what it is intended to do. [Suitable techniques - Specification derived tests, Equivalence partitioning, State-transition testing]

c. Existing test cases should be enhanced and further test cases should be designed to show that the software does not do anything that it is not specified to do i.e. Negative Testi ng [Suitable techniques - Error guessi ng, Boundary value analysis, Internal boundary value testi ng, State-transition testing]

d. Where appropriate, test cases should be designed to address issues such as performance, safety requirements and securi ty requirements [Suitable techniques - Specification derived tests]

e. Further test cases can then be added to the unit test specification to achieve specific test coverage objectives. Once coverage tests have been designed, the test procedure can be developed and the tests executed [Suitable techniques - Branch testing, Condition testing, Data definition-use testing, State-transi tion testing]

Test Case – Sample Structure

The manner in whi ch a test case is depicted varies between organizations. Anyhow, many test case templates are in the form of a table, for example, a 5-column table with fields:

Test Case
Test Case
Test Dependency/
Input Data Requi rements/
Expected
Pass/Fail
ID
Description
Setup
Steps
Results


Test Case Design Techniques

The test case design techni ques are broadly grouped into two categories: Black box techniques, White box techniques and other techniques that do not fall under either category.

Black Box (Functional)  White Box (Structural)   Other
-
-
-
Specification derived tests
Branch Testing
Er ror guessing
-
-
Equivalence partitioning
Condition Testing
-
-
Boundary Val ue Analysis
Data Definition - Use Testing
-
-
State-Transition Testing
Internal boundary value testing

The Test Planning Process

E3MABQ37MSQ9 What is a Test Strategy? W hat are its Components?

Test Policy - A document characterizing the organization’s philosophy towards software testing.

Test Strategy - A high-l evel document defining the test phases to be performed and the testing within those phases for a programme. It defines the process to be followed in each project. This sets the standards for the processes, documents, activities etc. that should be followed for each project.

For example, if a product is given for testing, you should decide if it is better to use black-box testi ng or white-box testing and if you decide to use both, when will you apply each and to which part of the software? All these details need to be specified in the Test Strategy.

Project Test Plan - a document defining the test phases to be performed and the testing within those phases for a particular project.

A Test Strategy should cover more than one project and should address the following issues: An approach to testing hi gh risk areas first, Planning for testing, How to improve the process based on previ ous testing, Environments/data used, Test management - Configuration management, Problem management, What Metrics are followed, Will the tests be automated and if so which tools will be used, What are the Testing Stages and Testing Methods, Post Testing Review process, Templates.

Test planning needs to start as soon as the project requi rements are known. The first document that needs to be produced then is the Test Strategy/Testing Approach that sets the high level approach for testing and covers all the other elements mentioned above.

Test Planning – Sample Structure

Once the approach is understood, a detailed test plan can be written. Usually, this test plan can be written in different styles. Test plans can completely differ from project to project i n the same organization.

IEEE SOFTWARE TEST DOCUMENTATION Std 829-1998 - TEST PLAN

Purpose

To describe the scope, approach, resources, and schedule of the testing activities. To identify the items being tested, the features to be tested, the testing tasks to be performed, the personnel responsible for each task, and the risks associated with this plan.

OUTLINE

1. A test plan shall have the following structure:

2. Test plan i dentifier. A unique identifier assign to the test plan.

3. Introduction: Summarized the software items and features to be tested and the need for them to be included.

4. Test items: Identify the test items, their transmittal media which impact their

5. Features to be tested

6. Features not to be tested

7. Approach

8. Item pass/fail criteria

9. Suspension criteria and resumption requirements

10. Test deliverables

11. Testing tasks

12. Environmental needs

13. Responsibilities

14. Staffing and training needs

15. Schedule

16. Risks and contingencies

17. Approvals

Most common software errors

Following are the most common software errors that aid you in software testing. This helps you to identify errors systematically and increases the efficiency and productivity of software testing.

Types of errors with examples


1. User Interface Errors

Missing/Wrong Functions, Doesn’t do what the user expects, Missing information, Misleading, Confusing information, Wrong content in Help text, Inappropriate error messages. Performance issues - Poor responsiveness, Can't redirect output, Inappropriate use of key board

2. Error Handling

Inadequate - protection against corrupted data, tests of user input, version control; Ignores – overflow, data comparison, Error recovery – aborting errors, recovery from hardware problems.

3. Boundary related errors

Boundaries in loop, space, time, memory, mishandling of cases outside boundary.

4. Calculation errors

Bad Logic, Bad Arithmetic, Outdated constants, Calculation errors,Incorrect conversion from one data representation to another, Wrong formula, Incorrect approximation.

5. Initial and Later states

Failure to  - set data item to zero, to initialize a loop-control variable, or re-initialize a pointer, to clear a string or flag, Incorrect initialization.

6. Control flow errors

Wrong returning state assumed, Exception handling based exits, Stack underflow/overflow, Failure to block or un-block interrupts, Comparison sometimes yields wrong result, Missing/wrong default, Data Type errors.

7. Errors in  Handling or Interpreting Data

Un-terminated null strings, Overwriting a file after an error exit or user abort.

8. Race Conditions

Assumption that one event or task finished before another begins,Resource races, Tasks starts before its prerequisites are met, Messages cross or don't ar rive in the order sent.

9. Load Conditions

Required resources are not available, No available large memory area, Low pri ority tasks not put off, Doesn't erase old files from mass storage, Doesn't return unused memory.

10. Hardware

Wrong Device, Device unavailable, Underutilizing device intelligence, Misunderstood status or return code, Wrong operation or instruction codes.

11. Source, Version and ID Control

No Title or version ID, Failure to update multiple copies of data or program files.

12. Testing Errors

Failure to notice/report a problem, Failure to use the most promising test case, Corrupted data files, Misinterpreted specifications or documentation, Failure to make it clear how to reproduce the problem, Failure to check for unresolved problems just before release, Failure to verify fixes, Failure to provide summary report.