1.  System Requirement Specification and System Planning

2.  It is a first of any software product.  It start when you thinking about developing S/W.  In this phase, you meet customers, analyzing market requirement and feature that are in demand.  Spend some time in research and analysis.

3.  In this stage, marketing and sales person are direct contact with the customers do most of the work.  A comprehensive understanding of the customers needs and writing down features of the proposed software product are the key to success in this phase

4.  It is actually the base for the whole development effort.  If the base is not laid not correctly, the product will not find a place in the market.  If the base is laid correctly, the product will find a place in the market.  MRD that contain formal data representation.

5.  It is the process of determining user demand for new or modified product.  The requirement must be quantifiable, relevant and detailed are called functional specification.  Requirement analysis involves following activities

6.  1. Eliciting Requirement ◦ The task of communicate with customers and user to determine what their requirement are is called requirement gathering.

7.  Analyze requirement ◦ Determine whether the stated requirement are unclear, incomplete, ambiguous then resolving that issues.

8.  Recording requirement ◦ Requirement might be documented in various forms like natural-language document, use-cases, user stories, or process specification

9.  It is a team effort that demand a combination of H/W, S/W, human factors expertise as well as skill in dealing with people.  It is a long and hard process during process specification.  It is critical to the success of a development project.

10.  Requirement must be actionable, measurable, testable, related to identified business needs.  Requirement can be functional and non- functional  Steps in requirement analysis process are given below….

11.  Fix system boundaries  Requirement management  Identify the customers  Requirement identification  Requirement analysis process  Requirement specification ◦ User requirement- written in clear, precise language with plain text, use cases, for the benefits of the customers and end-user ◦ System requirement- expressed as a programming or mathematical model, addressing ADT, QA, TT

12.  Detailed description of the software that is developed for the software.  SRS is fully describe what the software will do.  How it will expected to perform.  The SRS minimize the time and effort and development cost.

13.  A good SRS define how an application will interact with system.  Such as operating speed, response time, availability, etc….  SRS document is a contract between the development team and customers.

14.  SRS is the beginning point of the software development activities.  The main assumption was that the developers understand the problem clearly.  The requirement analysis has to identify the requirement by talking to people and understanding their needs.

15.  Identifying requirement necessary involves specifying what some people have in their mind.  SRS phase is inherently informal and imprecise and likely to be incomplete. 

16.  A condition of capability needed by a user to solve a problem or achieve the objective.  A condition or capability that must be met or processed by a system to satisfies a contract, standard, specification etc…

17.  Function  Performance  External interface  Design constraint  SRS is basic contract between developer between and user/client/customers.

18.  Project requirement ◦ Cost, delivery, schedule, staffing, reporting procedure  Design solution ◦ Partitioned s/w into module and choosing data structure  Product assurance plan ◦ QA procedure, CM procedure, verification and validation

19.  Forces the user to consider their specification requirement carefully.  Enhances the communication between the user and developers.  Provide a firm foundation for the system design phase.

20.  Enables planning of validation, verification, acceptance procedure.  Enables project planning such as estimate cost and time.  Usable during maintenance phase.

21.  An SRS document should contain following:  Functional requirement of the system  Non-Functional requirement of the system  Constraint on the system

22.  It describe each of the function that the system needs to perform along with corresponding input and output data set.  The constraint on the function of a system may describe certain things that the system should or should not do.  For example a constraint on a function can describe how fast it can produce result.

23.  These requirement deals with the characteristics of the system can not be expressed functionally.  It also include reliability issues, accuracy of result, etc…  For example  Maintainability  Portability  usability

24.  SRS is known as black-box specification.  The system is considered as a black-box whose internal detail are not known.  Only its visible external behavior is documented.  Input output S

25.  SRS document concentrates on: ◦ “What” needs to be done. ◦ “How to do” or provide the solution

26.  SRS document serves as a contract:  Between development team the customers.  Should be carefully written.

27.  It defines a function of a software system or its component.  A function describe as a set of input, output, behavior.  Functional requirement may be calculations, technical detail, data manipulation and what a system is supposed to accomplish.

28.  Are associated with specific function.  The key goal of determine the “functional requirement” in a software product design and implementation.  Behavior requirement describe all the cases where the system uses the functional requirement are captured in use cases.

29.  It is supported by non-functional requirement (quality requirement).  How a system implements functional requirements is detailed in the system design.

30.  functional requirement are in contrast to other software design requirements referred to as non-functional requirement which are primarily based on the system performance, software quality attribute, reliability etc…  It specify particular result of the system.

31.  Functional requirement drive the application architecture of a system  Non-functional requirement drive the technical architecture of a system.  Functional requirement will contain a unique name and number and give brief summary.

32.  This information is used to help the reader understand why the requirement is needed.  In order to document the functional requirement of the system,   it is necessary to learn how to first identify the high-level functional requirement of the system.

33.  Traceability means that it would be possible to tell which design components corresponds to which requirement  Which code corresponds to which design components  Which test case corresponds to which requirement

34.  It is an important concept and frequently used during software development.  Used to study the impact of a bug on various requirement.  Which part of the design and code would be effected.

35.  To achieve traceability each functional requirement should be numbered uniquely, consistently.  It is a sub-discipline of requirement management within software development and system engineering.  Requirement traceability is describe and follow a requirement in both forward & backward.

36.  Traceability is about understanding how high-level requirement objective, goals, aims, demand are transfer into low-level requirement.  Its purpose ◦ The understand of product under development ◦ The ability to manage change

37.  Correct  Unambiguous  Complete  Consistent  Ranked for importance  Concise  Well-Structured  Black-box review  Conceptual integrity

38.  Response to undesired events  Verifiable  Maintainable  Portable  adaptable

39.  Analyst and developer want the specification to be correct.

40.  An SRS is unambiguous if, and only if, every requirement stated there in has only one interpretation.

41.  A simple judge this is, it should be all that is needed by the software designer to create the software.