System Requirements and initial questions

Requirements and questions EXTENDED
The client needs a software solution which has well defined set of features.

Essential and optional features
*** MoSCoW priority ***********************************
• Must have
• Should have
• Could have
• Won't have

Developing software to meet functional requirements with acceptable quality, on planned schedule, and within budget is a target pursued by every software development organization.
Answers to these questions can sometimes discover unrealistic business targets coupled with too low budget and or poor planing.

1. Who will be creating and writing the "initial product specifications, features and requirements":
a) Developer/Coder?
b) Customer?
c) Product manager - Neutral Tester?

2. Who will be reading/validating these specifications:
a) Product manager? Coder?
b) Customer? Tester? User?

3. Who will be maintaining these specifications (this can often be the hardest part)?
a) Product manager? Customer?
b) Coder?
c) Tester? User?

4. What is the purpose of the specifications? Is it to ensure that the software works as desired? Are specifications intended to fully cover all of the possible use cases, or only a cross-section? Are they "start-to-finish" tests, i.e., a full business use case, or are they scenarios?
Do we have test cases data sets (input / desired output) upon the future software will perform?
Is customer providing a real examples of a formal use cases, with real production data?

5. Will customer also provide a Constant Product Testing and inspections in order to find out if the product features meet all his requirements and test specifications?


7. Software Precedentedness questions
7.1 Organizational understanding of product objectives / business logic / customer needs
a.General
b.Considerable
c.Thorough

7.2 Experience in working with and/or developing related software systems
a.Moderate
b.Considerable
c.Extensive

7.3 Concurrent development of associated new features and operational procedures
a.Extensive
b.Moderate
c.Some

8. Development Flexibility questions
8.1 Need for software conformance with pre-established requirements
a.Full
b.Considerable
c.Basic

8.2 Need for software conformance with external interface specifications
a.Full
b.Considerable
c.Basic

8.3 Premium on early completion
a.High
b.Medium
c.Low


So, so far, I believe development is far more a complex process than just writing code. And coding is far more complex that just writing an executable set of instructions for a machine (Description of a solution, remember?) Thus, I proclaim that coding is not the same as developing.
“The Fundamental Rules” of Software Engineering

1) If you don’t do a system architectural design with well-defined interfaces, integration will be a big mess.

2) Design before coding.

---------------------------
3) Requirements Checklists
---------------------------
Requirements checklists should address and identify:
- is there duplicated information?
- missing information
- is something vague or unclear?
- Use cases set and scenarios will help gathering, organizing and verifying requirements.
- review possible software reuse - feedback from previous work efforts

-------------------------------
4) GENERAL SPECIFICATIONS
-------------------------------
In this early stage it is clear :
- what are the files in the system repository, and what is their record structure
- what is desired behaviour of the software modules and objects
- feature specification list
- test data and test scenarios / input and desired output
Customer must be aware that in general lines, the software requirements should be set in stone before Development CYCLUS begins, in order not to wasted work put into a design and development based on incorrect requirements.
- what must be done in order to collect ALL input data
- the customer should provide SOME input data examples
- what must be done in order to process input data files into desired output behaviour and data.
- Make sure everyone knows the cost of requirements changes Clients get excited when they think of a new feature.
Who has requirements authority?
Someone has to define the requirements and get them approved by the necessary par-
ties (clients or end-user advocate).
How often will requirements and designs be reviewed, and how will adjustments be decided?

Startup Conditions
Create clear Startup Conditions Checklist - Explain what is missing for the project kick-off.

8) Using better and fewer people is more productive than using more less qualified people [2]

10) The earlier problems are discovered, the less the overall cost will be [7].
Testing while coding is the fundamental idea behind the iterative software growth stages.
- Planning of the iterative software growth stages,
- tests case examination scenario, with input parameters and desired output data must be done upfront, before the coding starts.
- specify valid test case
- create a sequence of test instances in a batch,
- MILESTONE development planning, starting with very simple but functional code
- monitor test case execution in a Log file, and report success, failure, and a type of error or warning during and after the execution of the code


12) Reviews of non-technical documents (e.g., requirements specification, user manual) are more effective if the customer is involved [10].

15) Extreme time pressure leads to a faster rate at which errors are made, which leads to a further delay in the completion date [9]. Extreme time pressure leads to decreased productivity [7].

18) Always test everything.

19) Talk to users, not to customers to verify the prototype.

21) Software inspections find a high percentage of errors early in the development life cycle [13].

22) The use of inspections can lead to defect prevention, because developers get early feedback with respect to the types of mistakes they are making [13].

26) Changing requirements are inevitable. Anticipating change with open architectures, adaptable designs, and flexible planning can help to mediate some of the ill effects of these changes [6].

27) Design for change/variability.

30) Successful software is designed by people who understand the application of the software (e.g., a well-designed missile control program was designed by someone who understood missiles) [8].

34) Tests reveal errors in the code. The better a test is prepared for, the higher amount of detected errors.

36) Motivation is increased through monetary incentives (profit sharing, pay for performance, merit pay, work measurement with incentives, and morale measurement), creating a positive frame of mind at work (employee involvement in wellness programs and creating fun at work), encouraging a feeling of commitment and responsibility (worker participation in decision-making, getting employees to think like owners, self-managing work teams, commitment to productivity breakthroughs, and providing an environment with more freedom and less restrictions), and increasing schedule pressure (using visible milestones and setting individual goals.) Increased motivation leads to increased productivity which reduces cycle time [13].

37) Improving the work environment is done by making ergonomic considerations, giving employees enclosed offices to reduce background noise and interruptions, and giving employees access to required resources, such as computers, software tools, support staff, and information. Improving the work environment leads to increased productivity, which reduces cycle time [13].

39) Improving the software development process can be done by formalizing the process, controlling quality, and taking advantage of tools. [13].

40) Rework is usually due to customer requirements, product flaws, and communication breakdown between project members. Improving the process to reduce rework can be done by using prototyping and evolutionary development and by using formal specification methods, modern programming practices, and inspections. Reducing rework increases productivity [13].

41) REDUCING OVERALL COMPLEXITY can be achieved. Product complexity can be reduced by reducing code complexity, design complexity, cognitive complexity, test complexity, and management complexity.
• Design complexity reduction is obtained by using object-oriented design techniques
• Code complexity reduction is achieved by using modularization and object-oriented programming techniques
• Cognitive complexity reduction is achieved by modularization, multiple levels of abstraction, simulation, and prototyping
• Test complexity can be reduced by using testing tools, building the product with testing in mind, and testing for the type of environment a product will be used in.
• Management complexity can be reduced by using project management planning tools and methods.
Reducing design, code, cognitive, test and management complexity reduces product complexity which increases productivity [13]

45) Tasks can be eliminated or simplified by using automation of tasks (e.g., code generators, automated testing) and eliminating non-value added activities and low-priority tasks. This leads to increased productivity [13].

46) Risk can be reduced by using risk management techniques. Reducing risk leads to increased productivity [13].

47) Nine ways to reduce cycle time are: increase productivity, reduce rework, maximize software reuse, reduce product complexity, eliminate or simplify tasks, maximize task concurrency, reduce undiscovered work, reduce risk, and use process models aimed at cycle time reduction [13].

48) Productivity is increased by increasing motivation, improving the work environment, getting the best people for the job, improving the process, and maximizing reuse [13].
50) Decisions made in the upstream portion of the software development process (requirements and design) impact productivity, quality, and costs throughout the life cycle more than the other portions [5].

52) Specification mistakes often occur when designers do not have sufficient application knowledge to interpret the customer’s intentions from the requirements document [5].

53) Requirements will appear to fluctuate when the development team lacks application knowledge and performs an incomplete analysis of the requirements [5].

54) CONSTANT COMMUNICATION
Coordinating understanding of an application and its environment context requires constant communication between customers and developers [5].

55) AMBIGUITIES ELIMINATION
Specifications are almost always incomplete and fraught with ambiguities. Constant contact with the customer is required to obtain the correct requirements. Without this communication, the developers tend to make incorrect assumptions about what the customer wants [6].

56) Fluctuating and conflicting requirements is a major phenomenon that greatly reduces software productivity and quality [5].

57) Communication and coordination collapse is a major phenomenon that greatly reduces software productivity and quality [5].

58) TRULY EXCEPTIONAL SOFTWARE ARCHITECTS ARE RARE RESOURCE
Truly exceptional software architects, developers & designers that are extremely familiar with the application domain, skilled at communicating their technical vision to other project members, possess an exceptional ability to map between the behaviour required of the application system and the computational structures that implement the behaviour, and are recognized as the “intellectual core” of the project are a scarce resource [5].

59) New requirements frequently emerge during development since they could not be identified until portions of the system had been designed or implemented [5].

60) Besides a developer’s ability to design and implement programs, his skills in resolving conflicting requirements, negotiating with the customer, ensuring that the development staff shares a consistent understanding of the design, and providing communications between two contending groups are crucial to project performance [5].

61) Undiscovered work (work that was not considered in initial planning estimates) can be reduced by using formal methods, analysis of PERT sizing metrics, the Spiral life cycle model, and prototyping. Reducing undiscovered work leads to increased productivity [13].

63) Inspections should be thought of as part of the development process, and time must be set aside accordingly. Once this is done, inspections can have a significant improvement in the development organization’s ability to meet internal schedules. Proper use of inspections can even shorten life cycle [13].

65) Participants in the inspection team get a high degree of product knowledge, which leads to higher productivity [13].

66) Slower programmers show a great deal of improvement when using inspections [13].

69) Employers often limit the number of hours employees can work, resulting in further pressure to finish a project as quickly as possible [6].

70) The customer often changes deadlines to be earlier than originally agreed-upon, requiring negotiation with the customer for either allowing some deliverables to be delivered at the earlier date, with the rest being delivered later, or dropping some deliverables or requirements altogether [6].

71) Code comments and documentation are often produced at the end of a project, creating major problems when a team member is lost at short notice, leaving others to continue their work. This can be alleviated by having quality auditors require inspections at very short notice [6].

CRAB EFFECT
73) Sometimes the software used for development is upgraded to a new version during development, and despite claims that it is fully backward-compatible and won’t affect their work, it usually introduces new problems [6].

76) Matching the tasks to the skills and motivation of the people available increases productivity [2].

77) Employee motivation is the strongest influence of productivity [2].

78) Above a certain threshold, work conditions are not a powerful motivator, but below that threshold, they are a powerful de-motivator [2].

79) The training of new employees is usually done by the “old-timers,” which results in a reduced level of productivity on the “old-timer’s” part. Specifically, on the average, each new employee consumes in training overhead 20% of an experienced employee’s time for the duration of the training or assimilation period [1]. The average assimilation delay, the period of time it takes for a new employee to become fully productive, is 80 days [1].

81) As schedule pressure increases, quality assurance activities (especially walk-throughs and inspections) are often relaxed or suspended altogether [1].

82) In the absence of schedule pressure, a full-time employee allocates, on average, 60% of his working hours to the project (the rest is slack time: reading mail, personal activities, non-project related company business, etc.) [1].

83) Under schedule pressure, people tend to increase their percentage of working hours spent on the project by as much as 100%, due to spending less time on off-project activities, such as personal business and non-project communication, and/or working overtime [1].

85) The two “task -type” variables that have the greatest impact on programmer productivity are the programming language and the quality of external documentation [1].
References

---------------
Bibliography
---------------
1. Abdel-Hamid, T. and S.E. Madnick, Software Project Dynamics: an Integrated Approach. 1991, Upper Saddle River, NJ: Prentice-Hall, Inc.
2. Boehm, B.W., Software Engineering Economics. 1981, Upper Saddle River, NJ: Prentice Hall, Inc.
3. Brooks, F.P., The Mythical Man-Month: Essays on Software Engineering. 2 ed. 1995: Addison-Wesley. 336.
4. Bryan, G.E., Not All Programmers are Created Equal, in Software Engineering Project Management, R.H. Thayer, Editor. 1997, IEEE Computer Society: Los Alamitos, CA. p. 346-355.
5. Curtis, B., H. Krasner, and N. Iscoe, A Field Study of the Software Design Process for Large Systems. Communications of the ACM, 1988. 31(11): p. 1268-1287.
6. Dawson, R., Twenty Dirty Tricks to Train Software Engineers, in Proceedings of the 22nd International Conference on Software Engineering. 2000, ACM. p. 209-218.
7. Drappa, A. and J. Ludewig, Simulation in Software Engineering Training, in Proceedings of the 22nd Internation Conference on Software Engineering. 2000, ACM. p. 199-208.
8. Humphrey, W.S., Managing the Software Process. 1990: Addison-Wesley.
9. Levary, R.R. and C.Y. Lin, Modelling the Software Development Process Using an Expert Simulation System Having Fuzzy Logic. Software -- Practice and Experience, 1991. 21(2): p. 133-148.
10. Pressman, R.S., Software Engineering -- A Practitioner's Approach. 4 ed. 1997, New York, NY: McGraw-Hill.
11. Sackman, H., W.J. Erikson, and E.E. Grant, Exploratory Experimental Studies Comparing Online and Offline Programming Performance. Communications of the ACM, 1968. 11(1): p. 3-11.
12. Tang, J.C., Findings from Observational Studies of Collaborative Work, in Readings in Groupware and Computer-Supported Cooperative Work, R.M. Baecker, Editor. 1990, Morgan Kaufmann: San Mateo, CA. p. 251-259.
13. Tvedt, J.D., An Extensible Model for Evaluating the Impact of Process Improvements on Software Development Cycle Time. 1996, Ph.D. Dissertation, Arizona State University.
14. Weller, E.F., Lessons from Three Years of Inspection Data. IEEE Software, 1993. 10(5): p. 38-45.
Introduction
As software becomes increasingly important in systems that perform complex and critical functions, e.g., military defence, nuclear reactors, so too have the risks and impacts of software-caused failures. There is now general accord on the need to increase software reliability and quality by eliminating errors created during software development. Industry and academic institutions have responded to this need by improving developmental methods in the technology known as software engineering and by employing systematic checks to detect software errors during and in parallel with the developmental process.
Many organizations make the reduction of defects their first quality goal. Therefore, detecting and correcting a serious software defect would entail recalling hundreds of thousands of products. In the past 35 years, hundreds of research papers have been published in the areas of software quality, software engineering development process, software reliability modelling, software independent verification and validation (IV&V) and software fault tolerance. Software engineering is evolving from an art to a practical engineering discipline (Lyu 1996).
A large number of analytical models have been proposed and studied over the last two decades for assessing the quality of a software system. Each model must make some assumptions about the development process and test environment. The environment can change depending on the software application, the lifecycle development process as well as the capabilities of the engineering design team
(Malaiya 1990). Therefore, it is important for software users and practitioners to be familiar with all the relevant models in order to make informed decisions about the quality of any software product.
This chapter provides the basic concepts of software engineering assessment including software lifecycle, software development process and its applications, software verification and validation, and data collection and analysis.
Whether starting from scratch or redesigning, is all about planning and organization. Think long-term but focus on short-term -- and never lose sight of your customer.
The Core Process: A comprehensive, modifiable plan. A starting point for all kinds of teams and all kinds of budgets.