Major Steps in Requirements

n Analysis: Understanding Problem Domain, Modeling, Context Model, Dictionary of Terms: customer jargon vs. technical jargon, SRS-1 dictionary, Two approaches to analysis

n Elicitation: 3 main barriers:

Communication

Changes

Completeness

n Triage

n Specification: Basis for contracts

Typically, handed over to design team

Cost estimation & tracking

Testing

Thus, requirements must be:

Unambiguous & complete

Traceable

Feasible

Testable

Maintainable

n Verification and Validation

Requirements analysis in systems engineering and software engineering, encompasses those tasks that go into determining the needs or conditions to meet for a new or altered product, taking account of the possibly conflicting requirements of the various stakeholders, such as beneficiaries or users. It is an early stage in the more general activity of requirements engineering which encompasses all activities concerned with eliciting, analyzing, documenting, validating and managing software or system requirements

18. (Context: Design concepts) Explain Information hiding

The principle of information hiding suggests that modules be characterized by design decisions that each hides from all others. The use of information hiding as a design criterion for modular systems provides the greatest benefits when modifications are required during testing and later, during software maintenance.

19. What is FTR? Why do we need it?

A formal technical review (FTR) is a software quality assurance activity performed by software engineers with the following objectives:
- uncover errors in function, logic or implementation of the software.
- verify that the software meets its requirements.
- ensure that the software has been developed according to the standards.
- achieve uniform software.
- make projects manageable.

Each formal technical review is conducted as a meeting and is considered successful only if it is properly planned, controlled and attended.

20. What is coupling?

Coupling measures the strength of all relationships between functional units

The degree to which components depend on one another. There are two types of coupling, "tight" and "loose". Loose coupling is desirable for good software engineering but tight coupling may be necessary for maximum performance. Coupling is increased when the data exchanged between components becomes larger or more complex.

21. In terms of design, what is interface?

1. A user interface, consisting of the set of dials, knobs, operating system commands, graphical display formats, and other devices provided by a computer or a program to allow the user to communicate and use the computer or program. A graphical user interface (GUI) provides its user a more or less "picture-oriented" way to interact with technology. A GUI is usually a more satisfying or user-friendly interface to a computer system.

2. A programming interface, consisting of the set of statements, functions, options, and other ways of expressing program instructions and data provided by a program or language for a programmer to use.

3. The physical and logical arrangement supporting the attachment of any device to a connector or to another device.

Interface design encompasses three distinct, but related constructs--usability, visualization, and functionality

11. What is the real test of a good requirements document?

Correct.Each requirement must accurately describe the functionality to be delivered. The reference for correctness is the source of the requirement, such as an actual customer or a higher-level system requirements specification.

Feasible.It must be possible to implement each requirement within the known capabilities and limitations of the system and its environment.

Necessary.Each requirement should document something the customers really need or something that is required for conformance to an external requirement, an external interface, or a standard.

A good-quality requirement should exhibit the following characteristics that are missing from poorly specified requirements:

• Cohesiveness
• Completeness: Just as an entire requirements specification should be complete and contain all relevant requirements and ancillary material individual requirements should also be complete.
• Consistency
• Correctness: Defects in requirements will naturally lead to corresponding defects in the resulting architectures, designs, and implementations.
• Currency: All too often, requirements specifications are not updated when requirements change. They are also frequently not updated as the architecture is produced, sometimes resulting in changes in the underlying requirements.
• Customer/User Orientation
• External Observability
• Feasibility
• Lack of Ambiguity
• Mandatory
• Metadata
• Relevance
• Usability
• Validatability
• Verifiability

12.(Context: Source control) Describe branching/merging/ tagging.

Branching in CVS splits a project's development into separate, parallel histories. Changes made on one branch do not affect the other branches. Branching can be used extensively to maintain multiple versions of a product for providing support and new features.

Merging converges the branches back to the main trunk. In a merge, CVS calculates the changes made on the branch between the point where it diverged from the trunk and the branch's tip (its most recent state), then applies those differences to the project at the tip of the trunk.

13. What is SRS? Why do we need it?

SRS (Software Requirements Specifications)

SRS IS SOFTWARE REQUIREMENT SPECIFICATION DOCUMENT,WHICH

CONTAINS ALL THE INFORMATION REGARDING THE SYSTEM.IT

CONTAINS TECHNICAL AS WELL AS NON TECHNICAL

INFORMMATION.AFTER THE FEASIBILTY STUDY AN SRS IS PREPARED

BY A TEAM WHICH CONATAINS SYSTEM ANALYST,PROJECT

MANAGER,TEST LEAD AND CLIENT.

A software requirements specification (SRS) – a requirements specification for a software system – is a complete description of the behavior of a system to be developed. It includes a set of use cases that describe all the interactions the users will have with the software. In addition to use cases, the SRS also contains non-functional requirements. Non-functional requirements are requirements which impose constraints on the design or implementation (such as performance engineering requirements, quality standards, or design constraints).

14. What is Feature? Why do we need it?

Feature (software design) is an intentional distinguishing characteristic of a software item (in performance, portability, or - especially - functionality). A system is said to be feature-rich when it has many options and functional capabilities available to the user. Progressive disclosure is a technique applied to reduce the potential confusion caused by displaying a wealth of features at once.

15. (Context: Design patterns) Describe Singleton pattern. Give an example

The singleton pattern is one of the simplest design patterns: it involves only one class which is responsible to instantiate itself, to make sure it creates not more than one instance; in the same time it provides a global point of access to that instance. In this case the same instance can be used from everywhere, being impossible to invoke directly the constructor each time.

16. What are the characteristics of a good design?

n Recognizable architectural styles or patterns; components with good design characteristics; thereby facilitating implementation and testing

n Modularity

n Distinctness

n Independence of functional characteristics

n Little complexity of connections

17. What are some of the responsibilities of project manager?

V Project management consists of managing the production of a product within given time and funding limits. Since this requires human resources, project management involves not only technical and organizational skills, but also the art of managing people. Project management involves the planning, monitoring, and control of the people, process and events that occur as software evolves from preliminary concept to operational implementationPlanning, monitoring and control of

» People

» Process

» Events

Date: 2015-12-24; view: 777