Annuity
16 years ago
Monday, July 28, 2008
Requirement Specification
The software requirements specification is a document that lists out stakeholders’ needs and communicates these to the technical community that will design and build the system. The challenge of a well-written requirements specification is to clearly communicate to both these groups and all the sub-groups within.
To overcome this, Requirements Specifications may be documented separately as
User Requirements - written in clear, precise language with plain text and use cases, for the benefit of the customer and end-user
System Requirements - expressed as a programming or mathematical model, addressing the Application Development Team and QA and Testing Team.
Requirements Specification serves as a starting point for software, hardware and database design. It describes the function (Functional and Non-Functional specifications) of the system, performance of the system and the operational and user-interface constraints that will govern system development.
User Requirements - written in clear, precise language with plain text and use cases, for the benefit of the customer and end-user
System Requirements - expressed as a programming or mathematical model, addressing the Application Development Team and QA and Testing Team.
Requirements Specification serves as a starting point for software, hardware and database design. It describes the function (Functional and Non-Functional specifications) of the system, performance of the system and the operational and user-interface constraints that will govern system development.
Requirement Management
Requirements Management is the comprehensive process that includes all aspects of software requirements analysis and additionally ensures verification, validation and traceability of requirements. Effective requirements management practices guarantee that all system requirements are stated unambiguously, that omissions and errors are corrected and that evolving specifications can be incorporated later in the project lifecycle.
The purposes of Analysis & Design are:
1. To transform the requirements into a design of the system to-be.
2. To evolve a robust architecture for the system.
3. To adapt the design to match the implementation environment, designing it for performance.
An analysis mechanism represents a pattern that constitutes a common solution to a common problem. They may show patterns of structure, patterns of behavior, or both. They are used during analysis to reduce the complexity of analysis, and to improve its consistency by providing designers with a shorthand representation for complex behavior.
Mechanisms allow the analysis effort to focus on translating the functional requirements into software concepts without bogging-down in the specification of relatively complex behavior needed to support the functionality but not central to it.
2. To evolve a robust architecture for the system.
3. To adapt the design to match the implementation environment, designing it for performance.
An analysis mechanism represents a pattern that constitutes a common solution to a common problem. They may show patterns of structure, patterns of behavior, or both. They are used during analysis to reduce the complexity of analysis, and to improve its consistency by providing designers with a shorthand representation for complex behavior.
Mechanisms allow the analysis effort to focus on translating the functional requirements into software concepts without bogging-down in the specification of relatively complex behavior needed to support the functionality but not central to it.
The process of Requirement Analysis
Once all the stakeholder requirements have been gathered, a structured analysis of these can be done after modeling the requirements. Some of the Software Requirements Analysis techniques used are requirements animation, automated reasoning, knowledge-based critiquing, consistency checking, analogical and case-based reasoning.
It is always a next to impracticable job to get a) faultless requirements b) to do perfect analysis on the requirements c) lastly to convert them faultlessly into design or take to next SDLC level. In fact irrespective of metrics we use to measure requirements and take it to next level we should always keep in mind that the person who is gathering them and who is giving them both are human beings and lot of noise get introduced while in their communication. Hence requirements are bound to misled from their actual meaning to the understanding of gatherer.
This makes almost 30% of requirements either completely useless or almost impossible to convert them into a software product. Now should be done minimize such a huge gap. Almost all of the requirements should be supported by facts and data. Always remember the difference between stakeholders and end users, end users will be using your solutions so always double check any gathered requirement with them.
It is always a next to impracticable job to get a) faultless requirements b) to do perfect analysis on the requirements c) lastly to convert them faultlessly into design or take to next SDLC level. In fact irrespective of metrics we use to measure requirements and take it to next level we should always keep in mind that the person who is gathering them and who is giving them both are human beings and lot of noise get introduced while in their communication. Hence requirements are bound to misled from their actual meaning to the understanding of gatherer.
This makes almost 30% of requirements either completely useless or almost impossible to convert them into a software product. Now should be done minimize such a huge gap. Almost all of the requirements should be supported by facts and data. Always remember the difference between stakeholders and end users, end users will be using your solutions so always double check any gathered requirement with them.
Sunday, July 27, 2008
Requirement Analysis
Analysis
- Software engineering task bridging the gap between system requirements engineering and software design.
- Provides software designer with a model of:
- function
- behavior
- Model can be translated to data, architectural, and component-level designs.
- Expect to do a little bit of design during analysis and a little bit of analysis during design.
Analysis Objectives
- Identify customer’s needs.
- Evaluate system for feasibility.
- Perform economic and technical analysis.
- Allocate functions to system elements.
- Establish schedule and constraints.
- Create system definitions.
Thursday, July 24, 2008
Benefits of JAD sessions
If the above guidelines are followed closely, chances are, the JAD will be successful. A successful JAD session should provide these benefits:
Reduced system development time. In JAD, information can be obtained and validated in a shorter time frame by involving all participants (or at least a representative set of participants) who have a stake in the outcome of the session. JAD eliminates process delays and has been shown to reduce application development time between 20% to 50%.
Improved system quality and productivity. Much of the system’s quality depends on the requirements gathered. JAD involves users in the development life cycle, lets users define their requirements, thus ensures that the system developed satisfies the actual activities of the business. JAD is quoted the best method for collecting requirements from the users, customers, or customer advocates.
Reduced system cost. Much of the system development cost is in terms of man-hours of both system developers and business users involved. Reduced development time reduces the labor cost for developers, as well as users. Important process like requirement gathering requires the involvement and commitment of business area experts. The cost of taking them away from their daily operation is very high. JAD can reduce the involvement time of these business experts and hence reduce the cost further. Cost is also reduced by catching errors, misunderstandings and mistakes early in the development phrase. Studies have found that a majority of system errors result from early analysis errors, and the earlier these errors are corrected, the much less they will cost. The JAD sessions let designers and users work together in the very early of the development cycle, defining the scope, requirements of projects, resolving conflicts among different user groups. It put much efforts early in the life cycle in order to improve the quality and increase productivity and to reduce cost.
Enhanced communication and relationship between business end-users and IT personnel.
Cultivate ownership, easier acceptance (buy-in) and stronger commitment by users. The involvement of business end-users is no longer on advisory or consultation spectrum. It is the participation and contribution in the project development life-cycle. The more users contribute to the system, the easier for them to accept it and commit to it.
Reduced function creep. It was cited by Gary Anthes to be one of the best ways to reduce function creep, most of which results from poor initial requirements.
Enhanced education for participants and observers. By participating in JAD and be the medium between other users and IT, the business end-users will be kept fully informed about the progress of the system development.
Under the trends of emphasis on group work, quality and productivity, and attention shift from technology to business, the most frequently cited success indicators for applications were: timely delivery, achievement of business objectives, and building positive communications and relationships with customers. In the meantime, people are expecting higher productivity. Conducted properly, JAD can improvement all of these areas, and contribute greatly to development of a successful system.
http://www.umsl.edu
Reduced system development time. In JAD, information can be obtained and validated in a shorter time frame by involving all participants (or at least a representative set of participants) who have a stake in the outcome of the session. JAD eliminates process delays and has been shown to reduce application development time between 20% to 50%.
Improved system quality and productivity. Much of the system’s quality depends on the requirements gathered. JAD involves users in the development life cycle, lets users define their requirements, thus ensures that the system developed satisfies the actual activities of the business. JAD is quoted the best method for collecting requirements from the users, customers, or customer advocates.
Reduced system cost. Much of the system development cost is in terms of man-hours of both system developers and business users involved. Reduced development time reduces the labor cost for developers, as well as users. Important process like requirement gathering requires the involvement and commitment of business area experts. The cost of taking them away from their daily operation is very high. JAD can reduce the involvement time of these business experts and hence reduce the cost further. Cost is also reduced by catching errors, misunderstandings and mistakes early in the development phrase. Studies have found that a majority of system errors result from early analysis errors, and the earlier these errors are corrected, the much less they will cost. The JAD sessions let designers and users work together in the very early of the development cycle, defining the scope, requirements of projects, resolving conflicts among different user groups. It put much efforts early in the life cycle in order to improve the quality and increase productivity and to reduce cost.
Enhanced communication and relationship between business end-users and IT personnel.
Cultivate ownership, easier acceptance (buy-in) and stronger commitment by users. The involvement of business end-users is no longer on advisory or consultation spectrum. It is the participation and contribution in the project development life-cycle. The more users contribute to the system, the easier for them to accept it and commit to it.
Reduced function creep. It was cited by Gary Anthes to be one of the best ways to reduce function creep, most of which results from poor initial requirements.
Enhanced education for participants and observers. By participating in JAD and be the medium between other users and IT, the business end-users will be kept fully informed about the progress of the system development.
Under the trends of emphasis on group work, quality and productivity, and attention shift from technology to business, the most frequently cited success indicators for applications were: timely delivery, achievement of business objectives, and building positive communications and relationships with customers. In the meantime, people are expecting higher productivity. Conducted properly, JAD can improvement all of these areas, and contribute greatly to development of a successful system.
http://www.umsl.edu
Subscribe to:
Posts (Atom)
