␡
- Let's Review that Process...
- Meet Neil & Gordon...
- Task List
- The Development Process
- ...One More Time
- System Design
- Agile Waterfalls
- Use Cases
- What If...?
- UML State Diagrams
- An Example
- Specification Components
- User Requirements
- ...One More Time
- Creating executables
- Compiled or Interpreted?
- Just-in-Time...
This chapter is from the book
System Design
What’s the difference between the sound my cat makes walking on the piano and a the sounds made by a concert pianist? A plan.
When you’re programming, the plan you work with is a specification. (You knew that, right?)
Here are some things you need to know about specifications:
- There’s no single right way to prepare one.
- The detail required is determined by the complexity of the application and your experience. You’ll need to go into more detail when the subject or the functionality is new to you.
- Best practice dictates that the specification be developed during the course of the project, but that isn’t always possible. Sometimes your client (or your boss) wants a complete specification before you start coding. Be prepared. Either way requirements will change during the course of the project.
- Most non-trivial specifications will include a lot more than the use cases we’ll discuss here: database schemas, screen layouts, architectural and processing diagrams...the details will depend on the application. (Remember: it depends.) But this isn’t an application design book, so we’re just going to talk about a few design tools that will get you started. (We’ll look at a few others in later chapters.)