Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
What is the right way to write technical requirements for the UI component in an application? I guess it's not clear to me whether the technical requirement should dictate how the UI should be implemented or it should be as general as possible and describe what are required to satisfy the functional requirements and forget about the implementation details.
Here are my specific questions:
Should it state what technology the UI will be implemented in? (eg, ActiveX, WPF, HTML).
Should I describe the layout, the colors? (given that that can change)
Is it necessary to describe how the data is presented? (eg, does it need to say "data is displayed in a table or list format" or "a scrollbar shall appear is data cannot be fit on the screen"?)
Do I need to describe how the UI should react to user input if that is a functional requirement? (eg, the functional requirement says "it shall be clear to the user which action is current active"... should the technical requirement say "the button shall change color to Red when user selects option a.. Blue when user selects option b.. etc")
Is it necessary to state things that are common sense about the UI? For example,"it shall be position in such a way the entire content is visible"? or "it shall have shadow so that it stands out from the rest of the screen"? (note: these are not functional requirements but they apply to any UI in general)
There are no concrete rules here. The true answer is that it depends on what your team is composed of.
If the person writing the requirements is the technical lead, then it may well dictate the technology choice.
If however the person writing the requirements is a non-technical manager, then it's generally in the best interest to let the technical team decide on specifics while the manager merely dictates specific requirements that must be implemented.
Additionally, things like layout and colors probably don't have a place in technical requirements. Someone (whether it's the development team, or if available, a designer) should come up with mockups or wireframes to review with the users. This is an iterative process and can usually be done in parallel with some of the initial development (ie. developers can usually start writing domain models, database schemas, etc. while the designer iterates the UI with the users/stakeholders).
IMO, obvious things should be left out as they are just clutter, however, business rules such as validation, and screen states should absolutely.
Again, I want to reitorate that it entirely depends on the makeup of the team. The requirements doc is meant to communicate from one tier to another. And all decisions should be left to the tier best equipped to make those decisions.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I have been trying to learn the basics of software engineering principles, but I have come across a question that I cant find enough detail on to answer, any help would be appreciated:
For each of the process models (i.e. waterfall, incremental, prototyping
and spiral), how does the model handle a significant change in requirements late in the
development?
Thanks in advance.
I think this question can be simplified - broadly speaking there are two types of software development life cycle:
Iterative (or agile) methodologies like Scrum and Extreme Programming.
Sequential (or "big design upfront") methodologies like waterfall.
The iterative methodologies rely on the experiential feedback from within the project. In Scrum, the sprint review provides guidance concerning what can be achieved in the next sprint and the review of the product backlog can promote the latest requirements to the top of the priority list. In iterative methodology, the evaluation phase of the increment can feed into the planning for the next iteration.
These two examples show a clear point at which the methodologies can adapt and react to new requirements.
There are of course some specific details beyond this broad stroke explanation. For example, a Scrum team wouldn't actually change scope until the end of the sprint - unless the sprint was completely abandoned. As a result there could be a small delay before new requirements could begin implementation.
With the more traditional methodologies such as Waterfall, accommodating adaptation is more difficult because you are constrained by the current phase of the series of phases. To adapt requirements it's likely going to involve non-optimal design and implementation because of the nature of the change being bolted on. If the changes in the requirements were significant enough the entire development may be abandoned and restarted. At least with the agile methodologies you will have already developed, or in fact shipped, some increment of business value.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
When a software has a set of functionality where some of the functionality is provided with multiple implementations and the software automatically decides which one to use. So for instance:
An image editor that has image effects and some its effects like Blur, Median, etc is provided with both CPU and GPU implementations but not directly exposed to the user as options but rather the software decides which one to use based on the user's hardware.
Or in another case where the software chooses which sorting algorithm to use based on the data it has on the items to sort.
I guess this only happens in performance related features.
But what's the name of this feature/idea when a software has this workflow?
Is it called transparent execution? Or context sensitive? I seem to recall a term used to describe this behavior.
EDIT: Btw I am also interested in hearing the marketing term for this? Like ProgramX supports transparent execution.
This is strategy pattern.
You pass the same object to multiple implementations where the difference is the algorithm. This is a classic case of strategy pattern.
Sounds like the facade design pattern, from the GOF book page 185:
Provide a unified interface to a set
of interfaces in a subsystem. Facade
defines a higher level interface that
makes the subsystem easier to use.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
In a big corp, they often ask developers to fill in a matrix of what skills they have at what level. It's generally seen as a bit of a pain but is it actually useful, or another way for bureaucrats to try and reduce developers to a bunch of numbers on a spreadsheet?
Skills matrix are only partially helpful, they are good at giving you a general picture of your current "experience".
However these skills matrix does not include the most important aspect, the ability to learn.
This is the most important skill in IT in my view. And everyone learns at different speeds.
Eg. Throwing guy A into a new technology stack, and how long before he/she is productive?
Since IT/software development is a very wide field I regard skill sheets as quite useful. I used to be a Linux expert and my skill sheet reflected that. Then I shifted into iOS/Mac development and my now-employer asked me to fill out a skill sheet tuned to Mac... and I immediately noticed that I was novice in this field back then ;-) Vice versa, they were able to see whether I can fit into the company and where (in which team).
So of course they can be harmful if you lack the skills, but I think they make choices for employers easier (and I regard a big skill sheet in my CV as the most important part of the CV, even more so than the list of projects done).
The usefulness is totally dependent on what is being assessed. I work in an insurance company and this was done for all staff here. There was no category that I fit into and all the criteria were irrelevant.
I can see the benefit of assessing relevant criteria, it can identify weaknesses and target training, but those criteria need to be defined by someone who knows what you might not know.
Most of all, don't berate the bureaucrat for simplifying a complex object into a manageable set of information. As a programmer that's what you should be doing every day.
I think it is appropiate on big corps, but for small and specialized consultancies I would make a personal interview.
In big corporations if you dont fit in one place you may fit in other... in small teams I rather do personal assessment .
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I often see the phrases 'business logic' and 'application logic' in terms of web development (I assume it also applies to programming in general rather than just web development).
This is quite new to me so I don't really know what it means, could anyone please explain me what is exactly meant by this? Is it just a 'buzz word' used by programmers? Or?
Say you write a system which solves a business need for a customer.
The sum of all your code is the application logic, or system architecture - basically the entirety of the system you're building.
The business logic is the code subset which models and drives actual business processes. "What happens when an order for Product X is placed? How is the cost of Product Y calculated?" Ie. the bits of code where you probably need some input from the customer/domain expert/project stakeholder.
Ideally, the business logic is separated into its own tier or layer (see the Wikipedia article on N-tier architecture). The rest of the code can often simply be thought of as infrastructure to help that business logic execute (database wrapper, helper functions, service facades, external integration, GUI, etc).
Business logic is basically rules of the system according to functional specifications. For example Object A of type B must have attributed C and D, but not E.
Application Logic is more of a technical specification, like using Java servlets and OJB to persist to an Oracle database.
In the end, that are buzz words to help describe tiers of technology in an application. Hopefully in an effort to keep various tiers separated making a better application design.
It might be not very accurate, but I use the following thinking to determine whether it's application, business logic or something else:
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 4 years ago.
Improve this question
i'm currently in the process of modifying a legacy editor application and i need to add in a few data structures which i have made into a class of it's own which i later add to a collection object. but thus far i'm little bit blurry on where to put all of my functions which is related to that object. i'm thinking maybe OO like design, but i'm not quite sure how to do this in vb6. else all the functions are currently in a module mdl file. which are set as public function.
is there any good reference, book or whatever which i can learn more about how to properly design for vb6 app? for the current work and for future work i guess.
thanks.
Are you familiar with Rocky Lhotka's work? I would recommend reading Visual Basic 6 Business Objects.
Visual Basic 6 Business Objects provides a thorough introduction to employing objects that are used to model real-world business problems.
You can also visit www.lhotka.net
Edit :
I know it sounds like a lot of trouble, but I would really recommend you take the time and read Rocky's book. He talks about simulating OOP principles eg. like simulating inheritance in vb6 ect.
Another good source of information is Deborah Kurata, she's written a series of books about OO coding in VB. Less well known than Rocky Lhotka (who is excellent), and concentrates more on pure OO, not the ORM/DB layer that he does.
All the reference cited so far are good. However the Design Patterns by the Gang Of Four is usable for Visual Basic 6. The trick to remember that most of the pattern talked about in Design Patterns rely on implementing interfaces which VB6 can do well. In fact you will find most design patterns involve implementing interfaces.
This is because most design patterns focus on setting up how various objects interact as opposed to reusing behavior. So interface become much more important.
Design Patterns by the GoF
Patterns by Martin Fowler
The various GUI and presentation patterns is the most applicable in my opinion.
My own application is structured completely as a series of design patterns. For example I use a Passive View for my presentation layer. The various views called command objects which does the actual modifications of the model. I use factories to retrieve the list of reports, file types, and shapes my software support. All done in VB6 using the Design Patterns book by the GoF.
Before getting deep into the theological aspects of OOP those books cover you might begin by simply reading the VB6 documentation. In particular the sections on component design.