I am trying to prepare my first software design document. I am self-taught and have no formal training in CS. Having done a wee bit of reading up on it beforehand, I have created a list of Requirements, Qualities and Non-Qualities for the system, which provide an overview from a managerial viewpoint on what the project is tasked with providing. The intent was for these to be convertible into design Constraints, which in turn would guide justifiable design decisions. So far they do not get into many specifics of what resources are to be provided, but are general in that they should apply to all resources present in the system.
I am having difficulty, however, in proceeding to the next step. What exactly is a Design Constraint supposed to look like? How specific or general should it be? How do I convert domain Requirements into Constraints? Have I already gone nuts and over-specified things? :-)
I am the only programmer at a small service company. We have a current HTML with PHP PIs application which grew organically and has no test infrastructure. Editing one bit has repercussions and unintended consequences in far flung parts of the app. I want to replace it with a more professionally designed (in fact, any kind of designed) one, object-based with a test suite. Management doesn't know about programming and I need to know which of the current features are cruft, which workflows are bogged down, etc. This is intended to be my guidance both during a perpetually postponed design meeting and during implementation.
So far, I have the following:
- "Owner" refers to a company or division running their own deployment of the Software, with data independent of any other deployments.
- "Developer" means an individual who is either a programmer with write access to the source code, or a database admin working for an Owner.
- "User" means an individual who has authenticated access to a deployment.
- "Staff" means a User who works for an Owner.
- "Client" refers to a User who is a customer of an Owner.
What features must the service exhibit?
- Platforms: Access to the service must be available via a variety of recent-to-modern, general business computing devices. (i.e. desktop, laptop, tablet and smartphones as of 2013).
- Mobility: Reasonable efforts at providing access to the service for all Users must be made, regardless of their physical location.
- Secure: All data must require authentication and authorization to access, and non-safe requests must come with sufficient confirmation that they were initiated by user intent.
- Access Controls: Resources and sets of resources must have variable authorization permissions.
- Admin Powers: Read and write authorization to individual resources and sets of resources must be seperate.
- Unbreakable: The system must not be able to be put into a "broken" state by Users.
- No Clobber: A User should not be allowed to overwrite another user's changes unknowingly.
- Off-line: A User's scheduled events for the current day must be readable off-line.
- Rapid Bootstrap: New Staff must be able to get up to speed on the internal side of the system quickly.
- Owner Agnostic: Nothing specific to one Owner should be present in a new, clean deployment for another Owner.
- Brandable: An Owner must be able to configure the system to exhibit their branding and corporate specifics.
- Safe Data: A frequent and reliable back-up of all data must be easily scheduled.
What other features would we like the end product to exhibit?
- Fast developer turn-around for bug fixes.
- Fast prototyping for new features.
- Error-free implementation of new features.
- Regression-free changes.
- Attractive Client UI.
- Efficient Staff UI.
- Widest device and OS support reasonably achievable.
- All accountability/blame data (who did what, when?) should be involatile.
- All other data should be editable by a user with sufficient authorization, without needing a Developer.
- Data back-ups should be creatable on demand by a sufficiently authorized user.
- Data back-ups should be restorable on demand by a sufficiently authorized user.
What features are not important and will allow flexibility of design?
- Programming language choice
- UI monolingualism
- We do not need a generic resource import or export system.
- [this list is incomplete]