The key to effective teamwork is shared agreement on the expectations
of teammates concerning how the team will function. Standards may range
from assigning specific roles to each team member, to establishing protocols
for conduct and communication, to agreeing on what tools (version control,
word processor, etc.) the team will use. Team standards -- of all these
kinds -- establish a common understanding of expectations, and facilitate
efficient and effective collaboration. Without these norms teams have difficulty
communicating and cooperating since each individual may have a different
interpretation of how things should be done.
Although we will have regular peer evaluations at the class level, generally
associated with major deliverables, it is also important for the team to
do its own internal "self reviews". Your Team Standards document should
capture how often these get done, and what form they take.
The first task for a newly-formed team is to take an inventory of what
talents exist on the team...and what gaps there might be in the team's
capabilities that one should think about planning to fill. On a more personal
side, it's nice to get to know a little more the team members, including
some hobbies or special interests.This all has several purposes:
For the client:
This packet of information will provide the client with a preliminary overview
of the team working on the project. This will allow the client to better
understand what the team's strengths and weaknesses are, and how he/she
can best support the team.
For the team:
This provides the team with some knowledge of its collective strengths
and weaknesses. Clearly, this information will be instrumental in individual
task assignments, project selection, negotiating project specifications,
establishing design philosophy and strategy, project scheduling, and overall
project management.
In real life, a complete requirements document is a major milestone in the development of any software project. The requirements specification is a description of your project's requirements, both functional and non-functional, and forms the contractual basis for the expectations to be fulfilled by the development team. What this means concretely is that the specified features and performance detailed in the requirements document are the basis for “acceptance” of your final software product by the client; if your product meets the stated requirements, the project is closed...and you get paid. From this, it should be obvious that writing a strong and complete requirements document is an absolutely critical skill to master to future software engineers.
View Requirements DocumentIt's easy to come up with the most imaginative and crazy designs: magically updating distributed data stores, super fancy reactive graphical interfaces, massive networks of maps or nodes that all layout automatically and perfectly. We all know, however, that not all designs that you can imagine are feasible, meaning that they can't be implemented within the given cross-section of chosen platform, speed/usability goals, computational limitations, and other factors that frame your particular project. For these reasons, it's important to (a) develop a strong early grasp of the feasibility limitation that could exist in your project; and (b) to keep these in mind continually as you do requirements acquisition and early design. Too often we've had Capstone teams that have extracted requirements and envisioned a fabulous design that has them and their sponsor completed excited...only find out later (too late!) that certain key elements of their design simply aren't feasible. Developing an early understanding of what can and can't be done is a key to producing a good and successful design!
View Technological FeasibilityThe design specification is a description of your project's overall architectural design as well as the design of each major module. It is essentially the blueprint for your final product. If it is complete and well-executed, you should be able (in theory, at least) to send this document to any software development outfit and – without having anything more to go on – they would be able to realize your blueprint. As many software companies found out the hard way during the brief “software outsourcing to India” craze early in the last decade, reality is a little different: even with a very detailed software design specification, there are many tacit design details in the “context” of the design that are hard to impart to an outside team. In any case, a strong software design document serves to force you to make your implementation plans very explicit, and thereby often exposes problems in your envisioned architecture in plenty of time to think them through...rather than discovering them the hard way as you would if you had just started hacking away.
View Software Design DocumentA test plan outlines activities that are aimed at ensuring that your project's implementation exhibits the necessary functional and non-functional characteristics. In this document, you are asked to describe how you intend to ensure that the expectations presented in the requirements and design specification documents are met, via a well-planned software testing regime. If you feel your project should not involve one or more of these testing types, discuss the issue with your team mentor -- and be prepared to offer convincing rationale, since these testing types are widely prevalent and mostly applicable. This assignment write-up assumes that you are familiar with the basics of testing and quality assurance through your software engineering and other course materials, so it is relatively "light" on the details. Your past course material should give you a good reference point for these details.
View Software Testing Plan