Corporate Analysis of Requirement Specifications
Accepted Company’s Requirement Specification
The requirements for their system are very detailed and comprehensive. Every possible use case scenario has been accounted for with a desired process of its execution without going into implementation details. All system operations they require are simply presented in a hierarchical manner, each sub category being logically related to its super category. All user scenarios are covered as well as some basic ideas for how the system operations should relate. SLOBS have been extremely specific in their requirements yet not so specific that we as a software development company have no liberty in how we implement it. We will have no problem completing this product in the allotted time.
There were a few drawbacks, which seemed merely an oversight on SLOBS behalf. Some of the requirements are slightly vague but seem to result from our company having a lack of knowledge of how a library operates. These should easily be explained at our next design meeting with them.
Our company has chosen SLOBS to be the best company for us to extend our services too. Based upon the advantages discussed earlier we believe that we have enough knowledge to effectively deliver an accurate conceptual design and resulting product to SLOBS. We are already making the arrangements to discuss the monetary aspects of this with them.
Rejected Companies Requirement Specifications
This company has well defined requirements and for the most part has a very simple business structure. Plans for future expansion were stated up front allowing for the possibility of future business with this company. However, there are a number of complex compensation packages that must be implemented. The company was not able to convey these with clarity in the requirements document. There was also no mention of budget and since the company focus is on cutting as many costs as possible, it is safe to assume that this project will be under-funded. It is difficult to decide if the product can be delivered in the given time frame.
ScamJet has been rejected as their project has the potential to be a huge investment in time that will likely not have sufficient funding to cover development costs.
This company is very clear on what features their product is to have and what functionality it can perform. Unfortunately this system requires a lot of user input and the ability to over-ride what the program is doing, which creates the need for significantly increased error detection. The company is also seeking external support in the form of an 800-phone support line, which would be an ongoing expense. In addition, there is no specification of whether or not they are willing to purchase the storage hardware necessary to accommodate the amount of data that they are trying to store. Finally, they seem to know exactly what they want with little room for any negotiation.
HyperGlobalCompuNet has been rejected on the basis that their system is high in difficulty and its specifications are too rigid. The need for ongoing support staff is beyond the scope of the services that our company is offering.
This company is very clear and honest about what they are willing to spend. The requirements document was very descriptive and walked us through every possible state of the system. The drawbacks are, that the system required is going to cost way more than they are willing to spend. It will require extensive backing and massive data inputs creating a need for extra storage space. In addition the complexity of multiple user access and security will be expensive to implement.
DeWhy is expecting to get a very good bargain of some difficult to design software. Their expectations are way too high for what they are looking to compensate. This project would be a dead end financial endeavor.
The system that GAS wants produced is not feasible in the time allotted for it. The requirements specified are too specific in many areas leaving no room for our company to use its ingenuity; in the other areas it is just the opposite, very vague descriptions which would simply leave us guessing as to what they really want. The manner in which the requirements were presented was not very cognitive. Only after thorough study and cross-referencing were their points made clear. The difficulty level for the GAS system is much too complex since two interfaces, one at the pump and the other in the office, both requiring different functionality are needed.
GAS has set expectations much too high and has not provided enough (or in some cases too much) information needed to generate a conceptual idea. This project would not be a wise investment for our company to partake in.
After what seemed like hours of reading and technical research the COPS program was decided to be far too complex to create. The requirement specification they produced leaves little for a software development company to do; they have basically written a conceptual design instead of a requirement specification. The detail they have gone into is ridiculously too deep. The implementation aspect of it will require much more time than they expect. The security issues that must be dealt with for a wireless transmission from station to police car requires a lot more work as well.
COPS doesn’t need a software development company like ours to create their software, they seem to know how to do it themselves. There would be no room for negotiation with them on any of the aspects since they have already made up their minds. COPS have given us the "What" and the "How".