Question

Enter True of False

1. Software documentation is a support task.

2. If a compromise has to be made in development, software documentation can wait.

3. You have to know beforehand what kind of public the document you are about to produce addresses.

4. It is not better to express an idea in a simple way than risk an intricate, complex formulation.

5. Avoid having as many fields as possible filled in the screen shots that you take, so that your readers don’t get confused with information overload.

6. Communication is a key factor in the work of a technical writer.

7. The generic term for software documentation is "technical writing".

8. Every software product should include a ReadMe file with appropriate information.

9. The first thing you should think about when starting to write a manual is how your users are going to use it.

10. Most people read the software manual before using it.

11. The user interface needs to be easy to use even if the user does not have an overall systems understanding.

12. It is a good idea is to include links to a glossary of terms that might be more difficult to understand.

13. Although important, documentation cannot lead to system failure.

14. Managers and software engineers should pay as much attention to documentation and its associated costs as to the development of the software itself.

15. Some of the documents should tell users how to administer the system.

16. For large software projects, it is usually the case that documentation starts

being generated well before the development process begins.

17. Plans, schedules, process quantity documents and organizational and project standards are process documentation.

18. Process documentation describes the product that is being developed.

19. System documentation describes the product from the point of view of the users and managers.

20. Process documentation is produced so that the implementation of the system can be managed.

21. Product documentation is used before the system is operational.

22. Often the principal technical communication documents in a project are working papers.

23. Plans, estimates and schedules are documents which report how resources were used during the process of development.

24. The major characteristic of process documentation is that most of it becomes

outdated.

25. Test schedules are of little value during software evolution.

26. Product documentation is concerned with describing the design of the software

product.

27. System documentation is principally intended for maintenance engineers.

28. Users are responsible for managing the software used by end-users.

29. The functional description of the system outlines the system requirements and

briefly describes the services provided.

30. The system installation document is intended for system users.

31. The introductory manual should present a formal introduction to the system.

32. The system reference manual should describe the system facilities and their

usage.

33. An uncommon system maintenance problem is ensuring that all representations

are kept in step when the system is changed.

34. Document quality is important, but not as important as program quality.

35. Achieving document quality requires management commitment to

document design, standards, and quality assurance processes.

36. The first IEEE standard for user documentation was produced in 1967.

37. It is often a good idea to present two or more differently phrased descriptions of the same thing.

38. Documents should be inspected in the same way as programs.

39. Converting a word processor document to HTML usually produces effective on-line documentation.

40. The three phases of document preparation and associated support facilities are document creation, document polishing, and document editing.

41. A systems analyst should try to learn as much about a system as the user being interviewed.

42. Beginning analysts often overestimate the amount of work that a user performs.

43. System requirements define the functions to be provided by a system.

44. A usability requirement describes the dependability of the system.

45. Prototyping is not a method used in information gathering.

46. The most important step in preparing for an interview is to determine which users should be involved.

47. The most effective interviews are free-form, with no questions prepared in advance.

48. There is no advantage to having more than one project member present when interviewing users.

49. An activity diagram is a type of workflow diagram.

50. One advantage of JAD is that it reduces the requirements definition time.

51. Technical staff does not need to be included in JAD sessions.

52. The purpose of a structured walkthrough is to find problems and errors.

53. Define system requirements is not an activity in the analysis phase.

54. Reviewing existing forms is one of the fact-finding techniques.

55. Researching vendor solutions is not one of the fact-finding techniques.

56. Data flow diagrams are an important object-oriented technique.

57. A data flow is considered data in motion.

58. Details of a system are shown in a context diagram.

59. A level-0 diagram shows a system’s major processes.

60. In a DFD, it is sometimes possible for a process to have only inputs, but no outputs.

61. Functional decomposition is a non-iterative process.

62. Conservation of inputs and outputs is called balancing.

63. The software requirements specification document is sometimes called a functional specification.

64. The SRS tells the development team what to build.

65. The SRS is not used by the testing team.

66. The SRS can also be used to develop documentation.

67. Project scope is not a section of the SRS.

68. Requirements should be written in passive, not active voice.

69. Ambiguous language leads to verifiable requirements.

70. Redundancy in requirements leads to better maintainability.

Answer 1

1. Software documentation is a support task. --> False

2. If a compromise has to be made in development, software documentation can wait. --> False

3. You have to know beforehand what kind of public the document you are about to produce addresses. -->True

4. It is not better to express an idea in a simple way than risk an intricate, complex formulation. -->False

5. Avoid having as many fields as possible filled in the screen shots that you take, so that your readers don’t get confused with information overload.--> True

6. Communication is a key factor in the work of a technical writer. -->True

7. The generic term for software documentation is "technical writing".--> True

8. Every software product should include a ReadMe file with appropriate information.-->True

9. The first thing you should think about when starting to write a manual is how your users are going to use it. --> True

10. Most people read the software manual before using it. -->False

11. The user interface needs to be easy to use even if the user does not have an overall systems understanding. -->True

12. It is a good idea is to include links to a glossary of terms that might be more difficult to understand. -->False

13. Although important, documentation cannot lead to system failure. --> False

14. Managers and software engineers should pay as much attention to documentation and its associated costs as to the development of the software itself. -->True

15. Some of the documents should tell users how to administer the system. --> True

16. For large software projects, it is usually the case that documentation starts

being generated well before the development process begins. --> True

17. Plans, schedules, process quantity documents and organizational and project standards are process documentation. -->False

18. Process documentation describes the product that is being developed. --> True

19. System documentation describes the product from the point of view of the users and managers. --> False

20. Process documentation is produced so that the implementation of the system can be managed.-->True

21. Product documentation is used before the system is operational. --> False

22. Often the principal technical communication documents in a project are working papers. --> False

23. Plans, estimates and schedules are documents which report how resources were used during the process of development.--> True

24. The major characteristic of process documentation is that most of it becomes

outdated. --> True

25. Test schedules are of little value during software evolution. -->False

26. Product documentation is concerned with describing the design of the software

product.--> True

27. System documentation is principally intended for maintenance engineers. --> True

28. Users are responsible for managing the software used by end-users.--> True

29. The functional description of the system outlines the system requirements and

briefly describes the services provided.--> False

30. The system installation document is intended for system users.--> True

31. The introductory manual should present a formal introduction to the system.-->True

32. The system reference manual should describe the system facilities and their

usage.--> False

33. An uncommon system maintenance problem is ensuring that all representations

are kept in step when the system is changed. -->True

34. Document quality is important, but not as important as program quality.-->False

35. Achieving document quality requires management commitment to

document design, standards, and quality assurance processes. --> True

36. The first IEEE standard for user documentation was produced in 1967. --> False -->The first IEEE standard for user documentation was produced in 1987.

37. It is often a good idea to present two or more differently phrased descriptions of the same thing. --> False

38. Documents should be inspected in the same way as programs.--> True

39. Converting a word processor document to HTML usually produces effective on-line documentation. --> True

40. The three phases of document preparation and associated support facilities are document creation, document polishing, and document editing.--> True

41. A systems analyst should try to learn as much about a system as the user being interviewed.--> True

42. Beginning analysts often overestimate the amount of work that a user performs. --> False

43. System requirements define the functions to be provided by a system. -->True

44. A usability requirement describes the dependability of the system. --> False

45. Prototyping is not a method used in information gathering. --> True

46. The most important step in preparing for an interview is to determine which users should be involved. --> True

47. The most effective interviews are free-form, with no questions prepared in advance. -->False

48. There is no advantage to having more than one project member present when interviewing users. -->False

49. An activity diagram is a type of workflow diagram. --> True

50. One advantage of JAD is that it reduces the requirements definition time. --> False

51. Technical staff does not need to be included in JAD sessions.--> False

52. The purpose of a structured walkthrough is to find problems and errors. --> True

53. Define system requirements is not an activity in the analysis phase.--> False

54. Reviewing existing forms is one of the fact-finding techniques.--> True

55. Researching vendor solutions is not one of the fact-finding techniques. --> False

56. Data flow diagrams are an important object-oriented technique.--> True

57. A data flow is considered data in motion.--> True

58. Details of a system are shown in a context diagram.--> False

59. A level-0 diagram shows a system’s major processes.--> True

60. In a DFD, it is sometimes possible for a process to have only inputs, but no outputs.-->False

61. Functional decomposition is a non-iterative process. --> False

62. Conservation of inputs and outputs is called balancing. --> True

63. The software requirements specification document is sometimes called a functional specification. --> False

64. The SRS tells the development team what to build.--> True

65. The SRS is not used by the testing team.--> False

66. The SRS can also be used to develop documentation. -->True

67. Project scope is not a section of the SRS. --> Fasle

68. Requirements should be written in passive, not active voice.--> False. Requirements should always be written in the active voice using the subject(noun)-verb-object form. “Who” is responsible and “what” shall be done.

69. Ambiguous language leads to verifiable requirements. --> False.. Ambiguous language lead to confusion, wasted effort and rework.

70. Redundancy in requirements leads to better maintainability. --> False