Subjective Questions

1. List down some Standard Helpdesk problem.

1 Terminal kbd locked

2 Terminal 123x is hung

3 Terminal shows no cursor on the screen

4 Unable to start session

5 Unable to print from E-mail

6 Terminal 324x can’t access menu

7 Model X printer not printing

8 System logs user off

9 Unable to print reports

10 Terminal 789x unable to logon

11 Transactions abending

12 System drops session

13 Unable to get out of application

14 System accepts invalid data

15 Unable to connect with host

16 users cannot catalog

17 Cannot log on to e-mail

18 users hung in application

19 User unable to access printer

20 System sends error xyz

2. As Requirement analysis plays a major role in the s/w development life cycle, list out the four key attributes of requirements & explain. Give two quality checklists for each of the attributes.

• Complete. The requirements document includes all of the necessary requirements information. For example, whether or not SRS includes (Checklist): all the functions and nonfunctional requirements, constraints, external interface requirements, and data requirements that must be satisfied.

• Consistent. Internal conflicts do not exist between requirements in the document that result in the requirements contradicting each other. The requirements also do not conflict with higher-level requirements including business, user, or system-level requirements. Terminology should also be used consistently within the document: A word has the same meaning every time it is used. Two different words are not used to mean the same thing.

• Modifiable. The requirements document is organized and written in a manner that will facilitate making future change: Nonredundant: Each requirement is stated in only one place. Changeable: Each requirement can be changed without excessive impact on other requirements.

• Unambiguous. Each requirement statement should have only one interpretation, and each requirement should be specified in a coherent, easy-to-understand manner. For example, the author searches for words that end in “ly” (for example, quickly, user-friendly, automatically) because adverbs by nature are almost always ambiguous.

• Concise. Each requirement should be stated in short, specific, action-oriented language.

• Finite. The requirement should not be stated in an open-ended manner. For example, words like “all,” “every,” and “throughout” should be avoided in requirements statements.

• Measurable. Specific, measurable limits or values should be stated for each requirement as appropriate.

• Feasible. The requirement can be implemented using available technologies, techniques, tools, resources, and personnel within the specified cost and schedule constraints.

• Testable. 1. There exists a reasonably cost-effective way to determine that the software satisfies the requirement.

• Traceable. 1. Each requirement should be traceable back to its source (for example, user-level requirements, system-level requirements, standard, and enhancement request). 2. It should also be specified in a manner that allows traceability forward into the design, implementation, and tests.