Testing is sometimes incorrectly thought as an after-the-fact activity. Instead, testing should be performed at every development stage of the product. Test data sets must be derived and their correctness and consistency should be monitored throughout the development [...]]]> There is an often asked question about when testing should occur in the overall product development cycle?

Testing is sometimes incorrectly thought as an after-the-fact activity. Instead, testing should be performed at every development stage of the product. Test data sets must be derived and their correctness and consistency should be monitored throughout the development process. Testing should accompany each phase of “Software Development Life Cycle”. If testing is isolated as a single phase late in the cycle, errors in the problem statement or design may incur exorbitant costs. If this happens, not only must the original error be corrected, but the entire structure built upon it has to be changed. Therefore, testing should be involved throughout SDLC in order to bring out a quality product.

Testing Activities In Each Phase:

1. REQUIREMENTS ANALYSIS
• Determine correctness
• Generate functional test data.

2. Design
• Determine correctness and consistency
• Generate structural and functional test data.

3. PROGRAMMING
• Determine correctness and consistency.
• Generate structural and functional test data.
• Apply test data.
• Refine test data.

4. OPERATION & MAINTENANCE
• Retest

Of course, if you want to add examples of your own to substantiate this, please do so through the comments section.

* Users don’t understand what they [...]]]> For a process that is so critical to the success of a software project, you would be surprised at the number of problems that can happen during the requirements gathering and analysis process. This must be the reason why Requirements Analysis is called the ‘make-or-break’ step of any project.

* Users don’t understand what they want or users don’t have a clear idea of their requirements: Possibly the most common problem in the requirements analysis phase is that customers have only a vague idea of what they need, and it’s up to you to ask the right questions and perform the analysis necessary to turn this amorphous vision into a formally-documented software requirements specification that can, in turn, be used as the basis for both a project plan and an engineering architecture.
* Users won’t commit to a set of written requirements: There will always be the feeling that such a list is not complete, and can cause immense heartburn for the requirements analysts
* Users insist on new requirements after the cost and schedule have been fixed: This may occur because as development progresses and prototypes are developed, customers are able to more clearly see problems with the original plan and make necessary course corrections; it may also occur because changes in the external environment require reshaping of the original business problem and hence necessitates a different solution than the one originally proposed. Good project managers are aware of these possibilities and typically already have backup plans in place to deal with these changes.
* Communication with users is slow: The users and the requirements analysts are from different working environments with a different pace and style of working
* Users often do not participate in reviews or are incapable of doing so: Especially when dealing with customers from the non-software industry
* Users are technically unsophisticated
* Users don’t understand the development process.
* Technical personnel and end users may have different vocabularies. Consequently, they may wrongly believe they are in perfect agreement until the finished product is supplied.
* Engineers and developers may try to make the requirements fit an existing system or model, rather than develop a system specific to the needs of the client.
* Analysis may be often carried out by engineers or programmers, rather than personnel with the people skills and the domain knowledge to understand a client’s needs properly.

What can be done ? There are some steps that cam be taken to get over some of these difficulties:
# Ensure that you spend sufficient time at the start of the project on understanding the objectives, deliverables and scope of the project.
# Make visible any assumptions that the customer is using, and critically evaluate both the likely end-user benefits and risks of the project.
# Get your customer to read, think about and sign off on the completed software requirements specification, to align expectations and ensure that both parties have a clear understanding of the deliverable.
# Have a clearly defined process for receiving, analyzing and incorporating change requests, and make your customer aware of his/her entry point into this process.
# Set milestones for each development phase beyond which certain changes are not permissible — for example, disallowing major changes once a module reaches 75 percent completion
# Convert the software requirements specification into a project plan, detailing tasks and resources needed at each stage and modeling best-case, middle-case and worst-case scenarios.
# Ensure that the project plan takes account of available resource constraints and keeps sufficient time for testing and quality inspection
# Take notes at every meeting and disseminate these throughout the project team

Requirements are a description of how a system should behave or a description of system properties or attributes. It can alternatively be a statement of ‘what’ an application is expected to do. Requirements drive almost every activity, task, and deliverable in a software development project. Requirements must be actionable, measurable, [...]]]> What is Requirements Analysis ?

Requirements are a description of how a system should behave or a description of system properties or attributes. It can alternatively be a statement of ‘what’ an application is expected to do. Requirements drive almost every activity, task, and deliverable in a software development project. Requirements must be actionable, measurable, testable, related to identified business needs or opportunities, and defined to a level of detail sufficient for system design.
So, Requirements Analysis is the process of understanding the customer needs and expectations from a proposed system or application and is a well-defined stage in the Software Development Life Cycle model. Systematic requirements analysis is also known as requirements engineering. It is sometimes referred to loosely by names such as requirements gathering, requirements capture, or requirements specification. The term “requirements analysis” can also be applied specifically to the analysis proper (as opposed to elicitation or documentation of the requirements, for instance).

Conceptually, requirements analysis includes three types of activity:
* Eliciting requirements: the task of communicating with customers and users to determine what their requirements are.
* Analyzing requirements: determining whether the stated requirements are unclear, incomplete, ambiguous, or contradictory, and then resolving these issues.
* Recording requirements: Requirements may be documented in various forms, such as natural-language documents, use cases, user stories, or process specifications.

The Software Requirements Analysis Process covers the complex task of eliciting and documenting the requirements of all these users, modeling and analyzing these requirements and documenting them as a basis for system design.

Why is a thorough Requirements Analysis stage necessary?

Taking the time at the beginning of a project to define and document needs, features, and requirements enables you to establish traceability to ensure that your software requirements specification aligns with your business objectives and continues to do so throughout the project.
Studies reveal that inadequate attention to Software Requirements Analysis at the beginning of a project is the most common cause for critically vulnerable projects that often do not deliver even on the basic tasks for which they were designed. It is typically very costly to fix requirement errors that remain undiscovered until all the code has been written.

Why do we need requirements?

Requirements generated from the requirements analysis stage are used in a number of processes down the line, such as:
- Project scoping
- Cost estimating & Budgeting
- Project scheduling
- Software design
- Software testing
- Documentation and training manuals

Software design is a process of problem-solving and planning for a software solution. After the purpose and specifications of software is determined, software developers will design or employ designers to develop a plan for a solution. [...]]]> What is software design ? This is not a straight-forward question, but let me attempt to answer this question:

Software design is a process of problem-solving and planning for a software solution. After the purpose and specifications of software is determined, software developers will design or employ designers to develop a plan for a solution. It includes low-level component and algorithm implementation issues as well as the architectural view. The software requirements analysis (SRA) step of a software development process yields specifications that are used in software engineering. A software design may be platform-independent or platform-specific, depending on the availability of the technology called for by the design.
Design is a meaningful engineering representation of something that is to be built. It can be traced to a customer’s requirements and at the same time assessed for for quality against a set of predefined criteria for ‘good’ design. In the software engineering context, design focuses on four major areas of concern, data, architecture, interfaces, and components.
Designing software is an exercise in managing complexity. The complexity exits within the software design itself, within the software organization of the company, and within the industry as a whole. Software design is very similar to systems design. It can span multiple technologies and often involves multiple sub-disciplines. Software specifications tend to be fluid, and change rapidly and often, usually while the design process is still going on. Software development teams also tend to be fluid, likewise often changing in the middle of the design process. In many ways, software bears more resemblance to complex social or organic systems than to hardware. All of this makes software design a difficult and error prone process.
Software design documentation may be reviewed or presented to allow constraints, specifications and even requirements to be adjusted prior to programming. Redesign may occur after review of a programmed simulation or prototype. It is possible to design software in the process of programming, without a plan or requirement analysis, but for more complex projects this would not be considered a professional approach.