Software Design

1.0      Requirements Analysis

• 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.
• 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, not ‘how’.
• Software engineering task that bridges the gap between system level requirements engineering and software design.
• Software requirements analysis may be divided into give areas of effort
• Problem recognition
• Evaluation and synthesis
• Modeling
• Specification
• Review
• Requirements analysis encompasses those tasks that go into determining the requirements of a new or altered system, taking account of the possibly conflicting requirements of the various stakeholders, such as users.
• Requirements analysis is critical to the success of a project.
• 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.
• Requirements must be measurable, testable, related to identified business needs or opportunities, and defined to a level of detail sufficient for system design.
• Five common errors in requirements analysis:
• Customers do not really know what they want
• Requirements change during the course of the project
• Customers have unreasonable timelines
• Communication gaps exist between customers, engineers and project managers
• The development team does not understand the politics of the customer’s organization

2.0      Requirements Elicitation for Software

• Before requirements can be analyzed, modeled, or specified they must be gathered through an elicitation process.
• Initiating the Process
• The most commonly used requirements elicitation technique is to conduct a meeting or interview
• Facilitated Application Techniques
• This approach encourages the creation of a joint team of customers and developers who work together to identify the problem, propose elements of solution, negotiate different approaches and specify a preliminary set of solution requirements
• Quality Function Deployment
• A technique that translates the needs of the customer into technical requirements for software
• QFD identifies three types of requirements
• Normal requirements – the objectives and goals that are stated for a product or system during meeting with the customer
• Expected requirements – these requirements are implicit to the product or system and may be so fundamental that the customer does not explicitly state them
• Exciting requirements – these features go beyond the customer’s expectations and prove to be very satisfying when present
• Interviews
• A “traditional” means of eliciting requirements.
• It is important to understand the advantages and limitations of interviews and how they should be conducted.

 

 

 

• Use-Cases
• As requirements are gathered as part of informal meetings, FAST, or QFD, the software engineer can create a set of scenarios that identify a thread of usage for the system to be constructed.
• Prototype
• A valuable tool for clarifying unclear requirements.
• They can act in a similar way to scenarios by providing users with a context within which they can better understand what information they need to provide.
• There is a wide range of prototyping techniques, from paper mock-ups of screen designs to beta-test versions of software products, and a strong overlap of their use for requirements elicitation and the use of prototypes for requirements validation.

3.0      Analysis Principles

• All analysis methods are related by a set of operational principles
• The information domain of a problem must be represented and understood
• The functions that the software is to perform must be defined
• The behavior of the software must be represented
• The models that depict information, function, and behavior must be partitioned in a manner that uncovers detail in a layered fashion
• The analysis process should move from essential information toward implementation detail
• In addition to these operational analysis principles, a set of guiding principles for requirements engineering are suggested as
• Understand the problem before you begin to create the analysis model
• Develop prototypes that enable a user to understand how human/machine interaction will occurs
• Record the origin of an the reason for every requirement
• Use multiple view of requirements
• Rank requirements
• Work to eliminate ambiguity

4.0      Specification

• Specification principles
• Separate functionality from implementation
• Develop a model of the desired behavior of a system that encompasses data and functional response of a system to various stimuli from the environment
• Establish the context in which software operates by specifying the manner in which other systems components interact with software
• Define the environment in which the system operates and indicate how “a highly intertwined collection of agents react to stimuli in the environment (changes to objects) produced by those agents”
• Create a cognitive model rather than a design or implementation model. The cognitive model describes a system as perceived by its user community
• Recognize that “the specifications must be tolerant of incompleteness and augmentable.” A specification is always a model-an abstraction-of some real situation that is normally quite complex. Hence, it will be incomplete and will exist at many level of detail
• Establish the content and structure of a specification in a way that will enable it to be amenable to change

 

• Representation
• Representation format and content should be relevant to the problem
• Information contained within the specification should be nested
• Diagrams and other notational forms should be restricted in number and consistent in use
• Representations should be revisable

 

• The software requirements specification
• Is produced at the culmination of analysis task.
• The function and performance allocated to software as part of system engineering are refined by establishing a complete information description, a detailed functional description, a representation of system behavior, an indication of performance requirements and design constraints, appropriate validation criteria, and other information pertinent to requirements.
• Format of software requirements specification:
• Introduction
• Information description
• Functional description
• Behavioral description
• Validation criteria
• Bibliography and appendix

5.0      Specification Review

• A review of the Software Requirements Specification is conducted by both the software developer and the customer.
• Because the specification forms the foundation of the development phase, extreme care should be taken into conducting the review.
• Once the review is complete, the Software Requirements Specification is “signed-off” by both the customer and developer.

The specification becomes a “contract” for software development

Labels: Software Environment and Design